Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2026-31663 (GCVE-0-2026-31663)
Vulnerability from cvelistv5 – Published: 2026-04-24 14:45 – Updated: 2026-09-18 12:04- CWE-826 - Premature Release of Resource During Expected Lifetime
| URL | Tags |
|---|---|
| https://git.kernel.org/stable/c/4236c30b437b80f67… | |
| https://git.kernel.org/stable/c/0f451b43c88bf2b9c… | |
| https://git.kernel.org/stable/c/5002beda5cac69d52… | |
| https://git.kernel.org/stable/c/1c428b03840094410… | |
| https://access.redhat.com/security/cve/CVE-2026-31663 | vdb-entryx_refsource_REDHAT |
| https://bugzilla.redhat.com/show_bug.cgi?id=2461462 | issue-trackingx_refsource_REDHAT |
| https://security.access.redhat.com/data/csaf/v2/v… | x_sadp-csaf-vex |
| https://access.redhat.com/errata/RHSA-2026:67471 | vendor-advisoryx_refsource_REDHAT |
| https://access.redhat.com/errata/RHSA-2026:68570 | vendor-advisoryx_refsource_REDHAT |
| https://access.redhat.com/errata/RHSA-2026:68531 | vendor-advisoryx_refsource_REDHAT |
| https://access.redhat.com/errata/RHSA-2026:68532 | vendor-advisoryx_refsource_REDHAT |
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
acf568ee859f098279eadf551612f103afdacb4e , < 4236c30b437b80f673b9e08c8fae38b8d471ac9e
(git)
Affected: acf568ee859f098279eadf551612f103afdacb4e , < 0f451b43c88bf2b9c038b414be580efee42e031b (git) Affected: acf568ee859f098279eadf551612f103afdacb4e , < 5002beda5cac69d522dc54da0d5d463ed9c963d2 (git) Affected: acf568ee859f098279eadf551612f103afdacb4e , < 1c428b03840094410c5fb6a5db30640486bbbfcb (git) Affected: 69895c5ea0ca2e8d7de1e6d36965d0ab9730787f (git) Affected: 833760100588acfb267dac4d6a02ab9931237739 (git) Affected: e095ecaec6d94aa2156cceb98a85d409b51190f3 (git) Affected: 3.2.100 , < 3.3 (semver) Affected: 3.16.55 , < 3.17 (semver) Affected: 4.14.24 , < 4.15 (semver) |
guessed | |
| Linux | Linux |
Affected:
4.15
Unaffected: 0 , < 4.15 (semver) Unaffected: 6.12.94 , ≤ 6.12.* (semver) Unaffected: 6.18.23 , ≤ 6.18.* (semver) Unaffected: 6.19.13 , ≤ 6.19.* (semver) Unaffected: 7.0 , ≤ * (original_commit_for_fix) |
guessed | |
| Red Hat | Red Hat Enterprise Linux 10 |
Unaffected:
0:6.12.0-211.55.1.el10_2 , < *
(rpm)
cpe:/o:redhat:enterprise_linux:10.2 |
||
| Red Hat | Red Hat Enterprise Linux 8 |
Unaffected:
0:4.18.0-553.164.1.rt7.505.el8_10 , < *
(rpm)
cpe:/a:redhat:enterprise_linux:8::nfv |
||
| Red Hat | Red Hat Enterprise Linux 8 |
Unaffected:
0:4.18.0-553.164.1.el8_10 , < *
(rpm)
cpe:/o:redhat:enterprise_linux:8 |
||
| Red Hat | Red Hat Enterprise Linux 9 |
Unaffected:
0:5.14.0-687.49.1.el9_8 , < *
(rpm)
cpe:/a:redhat:enterprise_linux:9 cpe:/o:redhat:enterprise_linux:9 |
||
| Red Hat | Red Hat Enterprise Linux 6 |
cpe:/o:redhat:enterprise_linux:6
|
||
| Red Hat | Red Hat Enterprise Linux 7 |
cpe:/o:redhat:enterprise_linux:7
|
||
| Red Hat | Red Hat Enterprise Linux 9 |
cpe:/o:redhat:enterprise_linux:9
|
{
"containers": {
"adp": [
{
"affected": [
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:10.2"
],
"defaultStatus": "affected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 10",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "0:6.12.0-211.55.1.el10_2",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:enterprise_linux:8::nfv"
],
"defaultStatus": "affected",
"packageName": "kernel-rt",
"product": "Red Hat Enterprise Linux 8",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "0:4.18.0-553.164.1.rt7.505.el8_10",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:8"
],
"defaultStatus": "affected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 8",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "0:4.18.0-553.164.1.el8_10",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:enterprise_linux:9",
"cpe:/o:redhat:enterprise_linux:9"
],
"defaultStatus": "affected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 9",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "0:5.14.0-687.49.1.el9_8",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:6"
],
"defaultStatus": "unaffected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:7"
],
"defaultStatus": "affected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 7",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:7"
],
"defaultStatus": "affected",
"packageName": "kernel-rt",
"product": "Red Hat Enterprise Linux 7",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:9"
],
"defaultStatus": "unaffected",
"packageName": "kernel-rt",
"product": "Red Hat Enterprise Linux 9",
"vendor": "Red Hat"
}
],
"datePublic": "2026-04-24T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "A flaw was found in the Linux kernel\u0027s `xfrm` (IP eXtensible FRamework) subsystem. This vulnerability involves a race condition where a network device\u0027s reference is released too early during packet processing after asynchronous cryptography. This premature release can lead to the system attempting to access a deallocated device, potentially causing a system crash (Denial of Service)."
}
],
"metrics": [
{
"other": {
"content": {
"namespace": "https://access.redhat.com/security/updates/classification/",
"value": "Moderate"
},
"type": "Red Hat severity rating"
}
},
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-826",
"description": "Premature Release of Resource During Expected Lifetime",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-18T12:04:43.702Z",
"orgId": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"shortName": "redhat-SADP"
},
"references": [
{
"tags": [
"vdb-entry",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/security/cve/CVE-2026-31663"
},
{
"name": "RHBZ#2461462",
"tags": [
"issue-tracking",
"x_refsource_REDHAT"
],
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2461462"
},
{
"tags": [
"x_sadp-csaf-vex"
],
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-31663.json"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:67471"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:68570"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:68531"
},
{
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2026:68532"
}
],
"solutions": [
{
"lang": "en",
"value": "RHSA-2026:67471: Red Hat Enterprise Linux AppStream (v. 10), Red Hat Enterprise Linux BaseOS (v. 10), Red Hat Enterprise Linux CodeReady Linux Builder (v. 10), Red Hat Enterprise Linux Real Time (v. 10), Red Hat Enterprise Linux Real Time for NFV (v. 10)"
},
{
"lang": "en",
"value": "RHSA-2026:68570: Red Hat Enterprise Linux AppStream (v. 9), Red Hat Enterprise Linux BaseOS (v. 9), Red Hat Enterprise Linux CodeReady Linux Builder (v. 9), Red Hat Enterprise Linux Real Time (v. 9), Red Hat Enterprise Linux Real Time for NFV (v. 9)"
},
{
"lang": "en",
"value": "RHSA-2026:68531: Red Hat Enterprise Linux BaseOS (v. 8), Red Hat Enterprise Linux CRB (v. 8)"
},
{
"lang": "en",
"value": "RHSA-2026:68532: Red Hat Enterprise Linux NFV (v. 8), Red Hat Enterprise Linux RT (v. 8)"
}
],
"timeline": [
{
"lang": "en",
"time": "2026-04-24T00:00:00.000Z",
"value": "Reported to Red Hat."
},
{
"lang": "en",
"time": "2026-04-24T00:00:00.000Z",
"value": "Made public."
}
],
"title": "kernel: xfrm: hold dev ref until after transport_finish NF_HOOK",
"workarounds": [
{
"lang": "en",
"value": "Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability."
}
],
"x_adpType": "supplier",
"x_generator": {
"engine": "sadp-cli 1.0.0"
}
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/ipv4/xfrm4_input.c",
"net/ipv6/xfrm6_input.c",
"net/xfrm/xfrm_input.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4236c30b437b80f673b9e08c8fae38b8d471ac9e",
"status": "affected",
"version": "acf568ee859f098279eadf551612f103afdacb4e",
"versionType": "git"
},
{
"lessThan": "0f451b43c88bf2b9c038b414be580efee42e031b",
"status": "affected",
"version": "acf568ee859f098279eadf551612f103afdacb4e",
"versionType": "git"
},
{
"lessThan": "5002beda5cac69d522dc54da0d5d463ed9c963d2",
"status": "affected",
"version": "acf568ee859f098279eadf551612f103afdacb4e",
"versionType": "git"
},
{
"lessThan": "1c428b03840094410c5fb6a5db30640486bbbfcb",
"status": "affected",
"version": "acf568ee859f098279eadf551612f103afdacb4e",
"versionType": "git"
},
{
"status": "affected",
"version": "69895c5ea0ca2e8d7de1e6d36965d0ab9730787f",
"versionType": "git"
},
{
"status": "affected",
"version": "833760100588acfb267dac4d6a02ab9931237739",
"versionType": "git"
},
{
"status": "affected",
"version": "e095ecaec6d94aa2156cceb98a85d409b51190f3",
"versionType": "git"
},
{
"lessThan": "3.3",
"status": "affected",
"version": "3.2.100",
"versionType": "semver"
},
{
"lessThan": "3.17",
"status": "affected",
"version": "3.16.55",
"versionType": "semver"
},
{
"lessThan": "4.15",
"status": "affected",
"version": "4.14.24",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/ipv4/xfrm4_input.c",
"net/ipv6/xfrm6_input.c",
"net/xfrm/xfrm_input.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.15"
},
{
"lessThan": "4.15",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.94",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.23",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.13",
"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": "6.12.94",
"versionStartIncluding": "4.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.23",
"versionStartIncluding": "4.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19.13",
"versionStartIncluding": "4.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0",
"versionStartIncluding": "4.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "3.2.100",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "3.16.55",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.14.24",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: hold dev ref until after transport_finish NF_HOOK\n\nAfter async crypto completes, xfrm_input_resume() calls dev_put()\nimmediately on re-entry before the skb reaches transport_finish.\nThe skb-\u003edev pointer is then used inside NF_HOOK and its okfn,\nwhich can race with device teardown.\n\nRemove the dev_put from the async resumption entry and instead\ndrop the reference after the NF_HOOK call in transport_finish,\nusing a saved device pointer since NF_HOOK may consume the skb.\nThis covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip\nthe okfn.\n\nFor non-transport exits (decaps, gro, drop) and secondary\nasync return points, release the reference inline when\nasync is set."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The complete attacker-controlled path requires a local unprivileged user to create a user/net namespace, configure transport-mode XFRM state, send traffic, and tear down the namespace/device in parallel.\nAC:L - The race is attacker-controlled in the user-namespace scenario: the attacker controls packet injection and device/netns teardown and can repeat the sequence reliably.\nPR:L - XFRM and rtnetlink setup require CAP_NET_ADMIN, but these checks are against the network namespace user_ns and are reachable after unshare -Urn by an unprivileged local user.\nUI:N - No victim action is required once the attacker can run local code and create the namespace setup.\nS:U - The vulnerable component and impacted resource are the kernel itself; this is a standard kernel memory-safety issue rather than a VM or hardware boundary escape.\nC:H - This is a net_device use-after-free, and freed kernel heap objects can potentially be reclaimed and abused for kernel memory disclosure.\nI:H - Use-after-free in kernel networking code can potentially be shaped into control-flow or data-structure corruption, so high integrity impact is appropriate.\nA:H - The issue was reproduced as a KASAN slab-use-after-free in the async XFRM reinject path and can crash the kernel."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T12:24:13.957Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/4236c30b437b80f673b9e08c8fae38b8d471ac9e"
},
{
"url": "https://git.kernel.org/stable/c/0f451b43c88bf2b9c038b414be580efee42e031b"
},
{
"url": "https://git.kernel.org/stable/c/5002beda5cac69d522dc54da0d5d463ed9c963d2"
},
{
"url": "https://git.kernel.org/stable/c/1c428b03840094410c5fb6a5db30640486bbbfcb"
}
],
"title": "xfrm: hold dev ref until after transport_finish NF_HOOK",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-31663",
"datePublished": "2026-04-24T14:45:13.239Z",
"dateReserved": "2026-03-09T15:48:24.129Z",
"dateUpdated": "2026-09-18T12:04:43.702Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-31663",
"date": "2026-09-25",
"epss": "0.00133",
"percentile": "0.02294"
},
"microsoft_vex": {
"current_release_date": "2026-09-23T01:45:56.000Z",
"cve": "CVE-2026-31663",
"id": "msrc_CVE-2026-31663",
"initial_release_date": "2026-04-26T01:04:24.000Z",
"product_status:known_affected": "13",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "xfrm: hold dev ref until after transport_finish NF_HOOK",
"url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2026-31663.json",
"version": "17"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/ipv4/xfrm4_input.c",
"net/ipv6/xfrm6_input.c",
"net/xfrm/xfrm_input.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4236c30b437b80f673b9e08c8fae38b8d471ac9e",
"status": "affected",
"version": "acf568ee859f098279eadf551612f103afdacb4e",
"versionType": "git"
},
{
"lessThan": "0f451b43c88bf2b9c038b414be580efee42e031b",
"status": "affected",
"version": "acf568ee859f098279eadf551612f103afdacb4e",
"versionType": "git"
},
{
"lessThan": "5002beda5cac69d522dc54da0d5d463ed9c963d2",
"status": "affected",
"version": "acf568ee859f098279eadf551612f103afdacb4e",
"versionType": "git"
},
{
"lessThan": "1c428b03840094410c5fb6a5db30640486bbbfcb",
"status": "affected",
"version": "acf568ee859f098279eadf551612f103afdacb4e",
"versionType": "git"
},
{
"status": "affected",
"version": "69895c5ea0ca2e8d7de1e6d36965d0ab9730787f",
"versionType": "git"
},
{
"status": "affected",
"version": "833760100588acfb267dac4d6a02ab9931237739",
"versionType": "git"
},
{
"status": "affected",
"version": "e095ecaec6d94aa2156cceb98a85d409b51190f3",
"versionType": "git"
},
{
"lessThan": "3.3",
"status": "affected",
"version": "3.2.100",
"versionType": "semver"
},
{
"lessThan": "3.17",
"status": "affected",
"version": "3.16.55",
"versionType": "semver"
},
{
"lessThan": "4.15",
"status": "affected",
"version": "4.14.24",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/ipv4/xfrm4_input.c",
"net/ipv6/xfrm6_input.c",
"net/xfrm/xfrm_input.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.15"
},
{
"lessThan": "4.15",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.94",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.23",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.13",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:10.2"
],
"defaultStatus": "affected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 10",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "0:6.12.0-211.55.1.el10_2",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:enterprise_linux:8::nfv"
],
"defaultStatus": "affected",
"packageName": "kernel-rt",
"product": "Red Hat Enterprise Linux 8",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "0:4.18.0-553.164.1.rt7.505.el8_10",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:8"
],
"defaultStatus": "affected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 8",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "0:4.18.0-553.164.1.el8_10",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:enterprise_linux:9",
"cpe:/o:redhat:enterprise_linux:9"
],
"defaultStatus": "affected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 9",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "0:5.14.0-687.49.1.el9_8",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:6"
],
"defaultStatus": "unaffected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:7"
],
"defaultStatus": "affected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 7",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:7"
],
"defaultStatus": "affected",
"packageName": "kernel-rt",
"product": "Red Hat Enterprise Linux 7",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:9"
],
"defaultStatus": "unaffected",
"packageName": "kernel-rt",
"product": "Red Hat Enterprise Linux 9",
"vendor": "Red Hat"
}
],
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6B10F87F-6387-4CE3-9159-D77EB163C9AD",
"versionEndExcluding": "3.3",
"versionStartIncluding": "3.2.100",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C9F9D919-846F-4FDC-882F-B49219EA19E9",
"versionEndExcluding": "3.17",
"versionStartIncluding": "3.16.55",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4C6AA567-92EC-46CF-9ED1-2B04B2B29BFB",
"versionEndExcluding": "4.15",
"versionStartIncluding": "4.14.24",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "45125EC8-B49D-48DD-92B9-2E4D1295531E",
"versionEndExcluding": "6.18.23",
"versionStartIncluding": "4.15.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "1490EF9B-9080-481C-8D22-1306AAE664E4",
"versionEndExcluding": "6.19.13",
"versionStartIncluding": "6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:4.15:-:*:*:*:*:*:*",
"matchCriteriaId": "3B4D39AF-668B-442B-8085-639A6D4FA5AC",
"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\nxfrm: hold dev ref until after transport_finish NF_HOOK\n\nAfter async crypto completes, xfrm_input_resume() calls dev_put()\nimmediately on re-entry before the skb reaches transport_finish.\nThe skb-\u003edev pointer is then used inside NF_HOOK and its okfn,\nwhich can race with device teardown.\n\nRemove the dev_put from the async resumption entry and instead\ndrop the reference after the NF_HOOK call in transport_finish,\nusing a saved device pointer since NF_HOOK may consume the skb.\nThis covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip\nthe okfn.\n\nFor non-transport exits (decaps, gro, drop) and secondary\nasync return points, release the reference inline when\nasync is set."
}
],
"id": "CVE-2026-31663",
"lastModified": "2026-09-18T13:17:45.590",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.0,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.0,
"impactScore": 5.9,
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"type": "Secondary"
}
]
},
"published": "2026-04-24T15:16:45.947",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0f451b43c88bf2b9c038b414be580efee42e031b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1c428b03840094410c5fb6a5db30640486bbbfcb"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4236c30b437b80f673b9e08c8fae38b8d471ac9e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5002beda5cac69d522dc54da0d5d463ed9c963d2"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://access.redhat.com/errata/RHSA-2026:67471"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://access.redhat.com/errata/RHSA-2026:68531"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://access.redhat.com/errata/RHSA-2026:68532"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://access.redhat.com/errata/RHSA-2026:68570"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://access.redhat.com/security/cve/CVE-2026-31663"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2461462"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-31663.json"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-826"
}
],
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-09-17T15:00:49+00:00",
"cve": "CVE-2026-31663",
"id": "CVE-2026-31663",
"initial_release_date": "2026-04-24T00:00:00+00:00",
"product_status:fixed": "762",
"product_status:known_affected": "28",
"product_status:known_not_affected": "36",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: xfrm: hold dev ref until after transport_finish NF_HOOK",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-31663.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-21T16:54:55Z",
"cve": "CVE-2026-31663",
"id": "CVE-2026-31663",
"initial_release_date": "2026-04-25T01:36:40Z",
"product_status:first_fixed": "2",
"product_status:known_affected": "748",
"product_status:known_not_affected": "6",
"product_status:recommended": "382",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2026-31663",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-31663.json",
"version": "16"
}
}
}
CERTFR-2026-AVI-1203
Vulnerability from certfr_avis - Published: 2026-09-18 - Updated: 2026-09-18
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Elles permettent à un attaquant de provoquer un problème de sécurité non spécifié par l'éditeur.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 26.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2026-72436",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72436"
},
{
"name": "CVE-2026-43198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43198"
},
{
"name": "CVE-2026-64353",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64353"
},
{
"name": "CVE-2026-64214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64214"
},
{
"name": "CVE-2026-64046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64046"
},
{
"name": "CVE-2026-53091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53091"
},
{
"name": "CVE-2026-68459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68459"
},
{
"name": "CVE-2026-64376",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64376"
},
{
"name": "CVE-2025-40064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40064"
},
{
"name": "CVE-2026-68147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68147"
},
{
"name": "CVE-2026-53192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53192"
},
{
"name": "CVE-2026-64590",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64590"
},
{
"name": "CVE-2026-53230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53230"
},
{
"name": "CVE-2026-68343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68343"
},
{
"name": "CVE-2026-53398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53398"
},
{
"name": "CVE-2026-64552",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64552"
},
{
"name": "CVE-2026-53349",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53349"
},
{
"name": "CVE-2026-64287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64287"
},
{
"name": "CVE-2026-53381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53381"
},
{
"name": "CVE-2026-64270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64270"
},
{
"name": "CVE-2026-53132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53132"
},
{
"name": "CVE-2026-64275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64275"
},
{
"name": "CVE-2026-64274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64274"
},
{
"name": "CVE-2026-74394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74394"
},
{
"name": "CVE-2026-64485",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64485"
},
{
"name": "CVE-2026-53272",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53272"
},
{
"name": "CVE-2026-64561",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64561"
},
{
"name": "CVE-2026-52934",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52934"
},
{
"name": "CVE-2026-31493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31493"
},
{
"name": "CVE-2026-53179",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53179"
},
{
"name": "CVE-2026-64133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64133"
},
{
"name": "CVE-2026-64047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64047"
},
{
"name": "CVE-2026-74439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74439"
},
{
"name": "CVE-2026-68138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68138"
},
{
"name": "CVE-2026-64192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64192"
},
{
"name": "CVE-2026-52955",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52955"
},
{
"name": "CVE-2026-53350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53350"
},
{
"name": "CVE-2026-63974",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63974"
},
{
"name": "CVE-2026-68388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68388"
},
{
"name": "CVE-2026-53214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53214"
},
{
"name": "CVE-2026-46130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46130"
},
{
"name": "CVE-2026-68302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68302"
},
{
"name": "CVE-2025-27558",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27558"
},
{
"name": "CVE-2026-64452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64452"
},
{
"name": "CVE-2026-53210",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53210"
},
{
"name": "CVE-2026-52929",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52929"
},
{
"name": "CVE-2026-64492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64492"
},
{
"name": "CVE-2026-64483",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64483"
},
{
"name": "CVE-2026-63980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63980"
},
{
"name": "CVE-2026-64322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64322"
},
{
"name": "CVE-2024-58094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58094"
},
{
"name": "CVE-2026-64470",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64470"
},
{
"name": "CVE-2026-64461",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64461"
},
{
"name": "CVE-2026-64501",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64501"
},
{
"name": "CVE-2026-53002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53002"
},
{
"name": "CVE-2026-53090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53090"
},
{
"name": "CVE-2026-53274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53274"
},
{
"name": "CVE-2026-53202",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53202"
},
{
"name": "CVE-2026-74440",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74440"
},
{
"name": "CVE-2026-63921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63921"
},
{
"name": "CVE-2026-64513",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64513"
},
{
"name": "CVE-2026-64413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64413"
},
{
"name": "CVE-2026-68088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68088"
},
{
"name": "CVE-2026-64388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64388"
},
{
"name": "CVE-2026-64512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64512"
},
{
"name": "CVE-2026-64409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64409"
},
{
"name": "CVE-2026-52947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52947"
},
{
"name": "CVE-2026-53218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53218"
},
{
"name": "CVE-2026-64367",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64367"
},
{
"name": "CVE-2026-64077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64077"
},
{
"name": "CVE-2026-64380",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64380"
},
{
"name": "CVE-2026-64268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64268"
},
{
"name": "CVE-2026-53169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53169"
},
{
"name": "CVE-2026-64099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64099"
},
{
"name": "CVE-2026-74417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74417"
},
{
"name": "CVE-2026-64179",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64179"
},
{
"name": "CVE-2026-74569",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74569"
},
{
"name": "CVE-2026-64489",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64489"
},
{
"name": "CVE-2026-64510",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64510"
},
{
"name": "CVE-2026-53143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53143"
},
{
"name": "CVE-2026-64480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64480"
},
{
"name": "CVE-2026-64399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64399"
},
{
"name": "CVE-2026-72488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72488"
},
{
"name": "CVE-2026-72494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72494"
},
{
"name": "CVE-2026-74376",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74376"
},
{
"name": "CVE-2026-53161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53161"
},
{
"name": "CVE-2026-53271",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53271"
},
{
"name": "CVE-2026-53109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53109"
},
{
"name": "CVE-2026-52958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52958"
},
{
"name": "CVE-2026-64385",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64385"
},
{
"name": "CVE-2026-53193",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53193"
},
{
"name": "CVE-2026-64405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64405"
},
{
"name": "CVE-2026-72130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72130"
},
{
"name": "CVE-2026-53140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53140"
},
{
"name": "CVE-2026-72255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72255"
},
{
"name": "CVE-2026-64217",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64217"
},
{
"name": "CVE-2026-63818",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63818"
},
{
"name": "CVE-2026-64414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64414"
},
{
"name": "CVE-2026-53229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53229"
},
{
"name": "CVE-2026-53244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53244"
},
{
"name": "CVE-2026-64502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64502"
},
{
"name": "CVE-2026-64454",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64454"
},
{
"name": "CVE-2026-31486",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31486"
},
{
"name": "CVE-2026-64531",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64531"
},
{
"name": "CVE-2026-63993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63993"
},
{
"name": "CVE-2026-64308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64308"
},
{
"name": "CVE-2026-64407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64407"
},
{
"name": "CVE-2026-52999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52999"
},
{
"name": "CVE-2026-63832",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63832"
},
{
"name": "CVE-2026-64402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64402"
},
{
"name": "CVE-2026-68228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68228"
},
{
"name": "CVE-2026-72125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72125"
},
{
"name": "CVE-2026-63807",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63807"
},
{
"name": "CVE-2026-53231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53231"
},
{
"name": "CVE-2024-52560",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52560"
},
{
"name": "CVE-2026-31405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31405"
},
{
"name": "CVE-2026-53399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53399"
},
{
"name": "CVE-2026-53400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53400"
},
{
"name": "CVE-2026-63886",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63886"
},
{
"name": "CVE-2026-64221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64221"
},
{
"name": "CVE-2026-64365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64365"
},
{
"name": "CVE-2026-64025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64025"
},
{
"name": "CVE-2025-38717",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38717"
},
{
"name": "CVE-2026-64264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64264"
},
{
"name": "CVE-2026-64128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64128"
},
{
"name": "CVE-2026-72320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72320"
},
{
"name": "CVE-2026-46170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46170"
},
{
"name": "CVE-2026-53185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53185"
},
{
"name": "CVE-2026-31448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31448"
},
{
"name": "CVE-2026-53138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53138"
},
{
"name": "CVE-2026-63830",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63830"
},
{
"name": "CVE-2026-64256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64256"
},
{
"name": "CVE-2026-64319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64319"
},
{
"name": "CVE-2026-53391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53391"
},
{
"name": "CVE-2026-74345",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74345"
},
{
"name": "CVE-2026-52989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52989"
},
{
"name": "CVE-2026-63924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63924"
},
{
"name": "CVE-2026-72083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72083"
},
{
"name": "CVE-2026-64591",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64591"
},
{
"name": "CVE-2026-64333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64333"
},
{
"name": "CVE-2026-53141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53141"
},
{
"name": "CVE-2025-38187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38187"
},
{
"name": "CVE-2026-52924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52924"
},
{
"name": "CVE-2026-53227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53227"
},
{
"name": "CVE-2026-63979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63979"
},
{
"name": "CVE-2026-64404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64404"
},
{
"name": "CVE-2026-64467",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64467"
},
{
"name": "CVE-2026-63940",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63940"
},
{
"name": "CVE-2026-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53239"
},
{
"name": "CVE-2026-74521",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74521"
},
{
"name": "CVE-2026-23208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23208"
},
{
"name": "CVE-2026-53342",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53342"
},
{
"name": "CVE-2025-40139",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40139"
},
{
"name": "CVE-2026-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53181"
},
{
"name": "CVE-2026-52918",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52918"
},
{
"name": "CVE-2026-64424",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64424"
},
{
"name": "CVE-2026-64389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64389"
},
{
"name": "CVE-2026-53220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53220"
},
{
"name": "CVE-2026-64246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64246"
},
{
"name": "CVE-2025-71289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71289"
},
{
"name": "CVE-2026-64326",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64326"
},
{
"name": "CVE-2026-68085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68085"
},
{
"name": "CVE-2026-74401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74401"
},
{
"name": "CVE-2026-63870",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63870"
},
{
"name": "CVE-2024-49932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49932"
},
{
"name": "CVE-2026-64386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64386"
},
{
"name": "CVE-2026-72319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72319"
},
{
"name": "CVE-2026-53331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53331"
},
{
"name": "CVE-2025-38563",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38563"
},
{
"name": "CVE-2026-64460",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64460"
},
{
"name": "CVE-2026-64514",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64514"
},
{
"name": "CVE-2026-64082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64082"
},
{
"name": "CVE-2026-63821",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63821"
},
{
"name": "CVE-2026-68091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68091"
},
{
"name": "CVE-2026-64260",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64260"
},
{
"name": "CVE-2026-63805",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63805"
},
{
"name": "CVE-2026-64279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64279"
},
{
"name": "CVE-2026-63915",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63915"
},
{
"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-64383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64383"
},
{
"name": "CVE-2026-64337",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64337"
},
{
"name": "CVE-2024-14040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-14040"
},
{
"name": "CVE-2026-63888",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63888"
},
{
"name": "CVE-2026-64430",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64430"
},
{
"name": "CVE-2025-40054",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40054"
},
{
"name": "CVE-2026-68083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68083"
},
{
"name": "CVE-2026-52956",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52956"
},
{
"name": "CVE-2026-64459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64459"
},
{
"name": "CVE-2025-71074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71074"
},
{
"name": "CVE-2026-64295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64295"
},
{
"name": "CVE-2026-68089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68089"
},
{
"name": "CVE-2026-72466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72466"
},
{
"name": "CVE-2026-64592",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64592"
},
{
"name": "CVE-2026-64178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64178"
},
{
"name": "CVE-2026-52915",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52915"
},
{
"name": "CVE-2026-64177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64177"
},
{
"name": "CVE-2026-64497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64497"
},
{
"name": "CVE-2026-53163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53163"
},
{
"name": "CVE-2026-64258",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64258"
},
{
"name": "CVE-2026-68090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68090"
},
{
"name": "CVE-2026-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53146"
},
{
"name": "CVE-2026-64599",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64599"
},
{
"name": "CVE-2026-68461",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68461"
},
{
"name": "CVE-2026-64189",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64189"
},
{
"name": "CVE-2026-72339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72339"
},
{
"name": "CVE-2026-63798",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63798"
},
{
"name": "CVE-2026-53354",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53354"
},
{
"name": "CVE-2026-64598",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64598"
},
{
"name": "CVE-2026-53345",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53345"
},
{
"name": "CVE-2026-53205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53205"
},
{
"name": "CVE-2026-63810",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63810"
},
{
"name": "CVE-2026-64098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64098"
},
{
"name": "CVE-2026-63801",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63801"
},
{
"name": "CVE-2026-63815",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63815"
},
{
"name": "CVE-2026-63827",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63827"
},
{
"name": "CVE-2026-64304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64304"
},
{
"name": "CVE-2026-64451",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64451"
},
{
"name": "CVE-2026-64557",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64557"
},
{
"name": "CVE-2026-46158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46158"
},
{
"name": "CVE-2026-74267",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74267"
},
{
"name": "CVE-2026-53397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53397"
},
{
"name": "CVE-2026-53309",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53309"
},
{
"name": "CVE-2026-68457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68457"
},
{
"name": "CVE-2026-46320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46320"
},
{
"name": "CVE-2026-53201",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53201"
},
{
"name": "CVE-2026-64276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64276"
},
{
"name": "CVE-2026-63948",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63948"
},
{
"name": "CVE-2026-64475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64475"
},
{
"name": "CVE-2026-64508",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64508"
},
{
"name": "CVE-2025-39933",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39933"
},
{
"name": "CVE-2026-68210",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68210"
},
{
"name": "CVE-2026-64237",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64237"
},
{
"name": "CVE-2025-39990",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39990"
},
{
"name": "CVE-2026-64323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64323"
},
{
"name": "CVE-2026-64438",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64438"
},
{
"name": "CVE-2025-38565",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38565"
},
{
"name": "CVE-2026-64261",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64261"
},
{
"name": "CVE-2026-64220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64220"
},
{
"name": "CVE-2026-52941",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52941"
},
{
"name": "CVE-2026-64271",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64271"
},
{
"name": "CVE-2026-31568",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31568"
},
{
"name": "CVE-2026-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53150"
},
{
"name": "CVE-2026-53327",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53327"
},
{
"name": "CVE-2026-74478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74478"
},
{
"name": "CVE-2026-52939",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52939"
},
{
"name": "CVE-2026-31668",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31668"
},
{
"name": "CVE-2026-64462",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64462"
},
{
"name": "CVE-2026-53147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53147"
},
{
"name": "CVE-2026-64455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64455"
},
{
"name": "CVE-2026-72383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72383"
},
{
"name": "CVE-2026-52942",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52942"
},
{
"name": "CVE-2026-46331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46331"
},
{
"name": "CVE-2026-64421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64421"
},
{
"name": "CVE-2026-64302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64302"
},
{
"name": "CVE-2026-74305",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74305"
},
{
"name": "CVE-2026-72129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72129"
},
{
"name": "CVE-2026-72299",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72299"
},
{
"name": "CVE-2026-74473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74473"
},
{
"name": "CVE-2026-64445",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64445"
},
{
"name": "CVE-2026-52935",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52935"
},
{
"name": "CVE-2026-64328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64328"
},
{
"name": "CVE-2026-53200",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53200"
},
{
"name": "CVE-2025-71073",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71073"
},
{
"name": "CVE-2026-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53183"
},
{
"name": "CVE-2026-64433",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64433"
},
{
"name": "CVE-2026-64165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64165"
},
{
"name": "CVE-2026-64272",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64272"
},
{
"name": "CVE-2026-23469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23469"
},
{
"name": "CVE-2026-53257",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53257"
},
{
"name": "CVE-2026-52931",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52931"
},
{
"name": "CVE-2026-53338",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53338"
},
{
"name": "CVE-2026-64253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64253"
},
{
"name": "CVE-2026-68476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68476"
},
{
"name": "CVE-2026-43464",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43464"
},
{
"name": "CVE-2026-64076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64076"
},
{
"name": "CVE-2026-68477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68477"
},
{
"name": "CVE-2026-74405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74405"
},
{
"name": "CVE-2026-64500",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64500"
},
{
"name": "CVE-2026-63806",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63806"
},
{
"name": "CVE-2026-53368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53368"
},
{
"name": "CVE-2026-64097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64097"
},
{
"name": "CVE-2026-74476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74476"
},
{
"name": "CVE-2026-72351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72351"
},
{
"name": "CVE-2025-39859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39859"
},
{
"name": "CVE-2026-63816",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63816"
},
{
"name": "CVE-2026-64330",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64330"
},
{
"name": "CVE-2026-53330",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53330"
},
{
"name": "CVE-2026-64348",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64348"
},
{
"name": "CVE-2026-53383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53383"
},
{
"name": "CVE-2026-64469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64469"
},
{
"name": "CVE-2026-53348",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53348"
},
{
"name": "CVE-2026-52919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52919"
},
{
"name": "CVE-2026-64310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64310"
},
{
"name": "CVE-2026-53006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53006"
},
{
"name": "CVE-2026-64280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64280"
},
{
"name": "CVE-2026-64362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64362"
},
{
"name": "CVE-2026-64327",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64327"
},
{
"name": "CVE-2026-64415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64415"
},
{
"name": "CVE-2025-38064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38064"
},
{
"name": "CVE-2026-64289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64289"
},
{
"name": "CVE-2026-64523",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64523"
},
{
"name": "CVE-2026-63800",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63800"
},
{
"name": "CVE-2026-64102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64102"
},
{
"name": "CVE-2026-64255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64255"
},
{
"name": "CVE-2026-68213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68213"
},
{
"name": "CVE-2026-64314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64314"
},
{
"name": "CVE-2026-64486",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64486"
},
{
"name": "CVE-2024-50217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50217"
},
{
"name": "CVE-2026-43009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43009"
},
{
"name": "CVE-2026-64267",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64267"
},
{
"name": "CVE-2025-68822",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68822"
},
{
"name": "CVE-2026-64341",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64341"
},
{
"name": "CVE-2026-74493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74493"
},
{
"name": "CVE-2026-31420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31420"
},
{
"name": "CVE-2026-72194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72194"
},
{
"name": "CVE-2026-63817",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63817"
},
{
"name": "CVE-2026-64446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64446"
},
{
"name": "CVE-2026-53339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53339"
},
{
"name": "CVE-2026-64534",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64534"
},
{
"name": "CVE-2026-53266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53266"
},
{
"name": "CVE-2026-64338",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64338"
},
{
"name": "CVE-2026-64083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64083"
},
{
"name": "CVE-2026-53234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53234"
},
{
"name": "CVE-2026-53149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53149"
},
{
"name": "CVE-2026-63795",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63795"
},
{
"name": "CVE-2026-64106",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64106"
},
{
"name": "CVE-2026-64418",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64418"
},
{
"name": "CVE-2026-64249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64249"
},
{
"name": "CVE-2026-72222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72222"
},
{
"name": "CVE-2026-64536",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64536"
},
{
"name": "CVE-2026-46203",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46203"
},
{
"name": "CVE-2026-43213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43213"
},
{
"name": "CVE-2026-63873",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63873"
},
{
"name": "CVE-2026-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53176"
},
{
"name": "CVE-2026-31663",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31663"
},
{
"name": "CVE-2026-53172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53172"
},
{
"name": "CVE-2026-64010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64010"
},
{
"name": "CVE-2026-64364",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64364"
},
{
"name": "CVE-2026-63947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63947"
},
{
"name": "CVE-2026-43493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43493"
},
{
"name": "CVE-2026-68160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68160"
},
{
"name": "CVE-2026-64163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64163"
},
{
"name": "CVE-2025-68174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68174"
},
{
"name": "CVE-2026-72421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72421"
},
{
"name": "CVE-2024-50106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50106"
},
{
"name": "CVE-2026-63975",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63975"
},
{
"name": "CVE-2026-53233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53233"
},
{
"name": "CVE-2026-63952",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63952"
},
{
"name": "CVE-2026-53402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53402"
},
{
"name": "CVE-2026-64351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64351"
},
{
"name": "CVE-2026-64051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64051"
},
{
"name": "CVE-2026-63835",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63835"
},
{
"name": "CVE-2026-64432",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64432"
},
{
"name": "CVE-2025-40344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40344"
},
{
"name": "CVE-2026-53386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53386"
},
{
"name": "CVE-2025-21984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21984"
},
{
"name": "CVE-2026-64293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64293"
},
{
"name": "CVE-2026-74538",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74538"
},
{
"name": "CVE-2026-64039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64039"
},
{
"name": "CVE-2025-40354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40354"
},
{
"name": "CVE-2026-68087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68087"
},
{
"name": "CVE-2026-63833",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63833"
},
{
"name": "CVE-2026-63796",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63796"
},
{
"name": "CVE-2026-43499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43499"
},
{
"name": "CVE-2026-53332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53332"
},
{
"name": "CVE-2026-64363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64363"
},
{
"name": "CVE-2026-53401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53401"
},
{
"name": "CVE-2026-53334",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53334"
},
{
"name": "CVE-2026-74474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74474"
},
{
"name": "CVE-2026-64263",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64263"
},
{
"name": "CVE-2026-53353",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53353"
},
{
"name": "CVE-2026-68426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68426"
},
{
"name": "CVE-2026-64375",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64375"
},
{
"name": "CVE-2026-64296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64296"
},
{
"name": "CVE-2026-63917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63917"
},
{
"name": "CVE-2026-53335",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53335"
},
{
"name": "CVE-2026-45894",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45894"
},
{
"name": "CVE-2026-63926",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63926"
},
{
"name": "CVE-2026-64370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64370"
},
{
"name": "CVE-2026-53178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53178"
},
{
"name": "CVE-2026-53389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53389"
},
{
"name": "CVE-2025-68304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68304"
},
{
"name": "CVE-2026-64439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64439"
},
{
"name": "CVE-2025-40075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40075"
},
{
"name": "CVE-2026-72322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72322"
},
{
"name": "CVE-2026-64593",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64593"
},
{
"name": "CVE-2026-64254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64254"
},
{
"name": "CVE-2026-64231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64231"
},
{
"name": "CVE-2026-53158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53158"
},
{
"name": "CVE-2026-23240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23240"
},
{
"name": "CVE-2026-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53131"
},
{
"name": "CVE-2025-38069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38069"
},
{
"name": "CVE-2026-64091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64091"
},
{
"name": "CVE-2026-64299",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64299"
},
{
"name": "CVE-2026-72422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72422"
},
{
"name": "CVE-2026-64374",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64374"
},
{
"name": "CVE-2026-46181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46181"
},
{
"name": "CVE-2026-64357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64357"
},
{
"name": "CVE-2026-64488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64488"
},
{
"name": "CVE-2026-64603",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64603"
},
{
"name": "CVE-2026-53219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53219"
},
{
"name": "CVE-2026-64109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64109"
},
{
"name": "CVE-2026-53190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53190"
},
{
"name": "CVE-2026-64345",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64345"
},
{
"name": "CVE-2026-64085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64085"
},
{
"name": "CVE-2026-64368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64368"
},
{
"name": "CVE-2026-53251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53251"
},
{
"name": "CVE-2026-64518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64518"
},
{
"name": "CVE-2026-53249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53249"
},
{
"name": "CVE-2026-64166",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64166"
},
{
"name": "CVE-2026-53329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53329"
},
{
"name": "CVE-2026-53139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53139"
},
{
"name": "CVE-2026-53382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53382"
},
{
"name": "CVE-2026-64504",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64504"
},
{
"name": "CVE-2026-46315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46315"
},
{
"name": "CVE-2024-41008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41008"
},
{
"name": "CVE-2026-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53217"
},
{
"name": "CVE-2026-53276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53276"
},
{
"name": "CVE-2026-64148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64148"
},
{
"name": "CVE-2026-53262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53262"
},
{
"name": "CVE-2026-53346",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53346"
},
{
"name": "CVE-2026-53070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53070"
},
{
"name": "CVE-2026-72495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72495"
},
{
"name": "CVE-2026-53088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53088"
},
{
"name": "CVE-2026-63813",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63813"
},
{
"name": "CVE-2026-64320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64320"
},
{
"name": "CVE-2026-63992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63992"
},
{
"name": "CVE-2026-64155",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64155"
},
{
"name": "CVE-2026-64398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64398"
},
{
"name": "CVE-2026-64147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64147"
},
{
"name": "CVE-2026-72084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72084"
},
{
"name": "CVE-2026-64464",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64464"
},
{
"name": "CVE-2024-35948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35948"
},
{
"name": "CVE-2026-64297",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64297"
},
{
"name": "CVE-2026-53243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53243"
},
{
"name": "CVE-2026-72317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72317"
},
{
"name": "CVE-2026-63976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63976"
},
{
"name": "CVE-2026-68092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68092"
},
{
"name": "CVE-2025-40274",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40274"
},
{
"name": "CVE-2026-64343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64343"
},
{
"name": "CVE-2026-64473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64473"
},
{
"name": "CVE-2024-53098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53098"
},
{
"name": "CVE-2026-64397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64397"
},
{
"name": "CVE-2026-72200",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72200"
},
{
"name": "CVE-2026-63984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63984"
},
{
"name": "CVE-2026-53361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53361"
},
{
"name": "CVE-2026-64371",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64371"
},
{
"name": "CVE-2026-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-46330",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46330"
},
{
"name": "CVE-2026-53009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53009"
},
{
"name": "CVE-2026-53236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53236"
},
{
"name": "CVE-2026-64471",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64471"
},
{
"name": "CVE-2026-53225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53225"
},
{
"name": "CVE-2026-64180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64180"
},
{
"name": "CVE-2026-64468",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64468"
},
{
"name": "CVE-2026-53222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53222"
},
{
"name": "CVE-2024-43872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43872"
},
{
"name": "CVE-2026-72487",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72487"
},
{
"name": "CVE-2026-72033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72033"
},
{
"name": "CVE-2026-72434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72434"
},
{
"name": "CVE-2026-64449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64449"
},
{
"name": "CVE-2026-64602",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64602"
},
{
"name": "CVE-2026-64125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64125"
},
{
"name": "CVE-2026-64551",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64551"
},
{
"name": "CVE-2026-72472",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72472"
},
{
"name": "CVE-2026-53362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53362"
},
{
"name": "CVE-2026-64410",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64410"
},
{
"name": "CVE-2026-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53168"
},
{
"name": "CVE-2026-53173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53173"
},
{
"name": "CVE-2026-52922",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52922"
},
{
"name": "CVE-2026-53053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53053"
},
{
"name": "CVE-2026-64089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64089"
},
{
"name": "CVE-2026-53403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53403"
},
{
"name": "CVE-2026-63871",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63871"
},
{
"name": "CVE-2026-64048",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64048"
},
{
"name": "CVE-2026-53209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53209"
},
{
"name": "CVE-2026-63797",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63797"
},
{
"name": "CVE-2026-74410",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74410"
},
{
"name": "CVE-2024-49940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49940"
},
{
"name": "CVE-2026-64456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64456"
},
{
"name": "CVE-2026-72491",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72491"
},
{
"name": "CVE-2025-71202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71202"
},
{
"name": "CVE-2026-63858",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63858"
},
{
"name": "CVE-2026-64170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64170"
},
{
"name": "CVE-2026-68127",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68127"
},
{
"name": "CVE-2026-64306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64306"
},
{
"name": "CVE-2026-74264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74264"
},
{
"name": "CVE-2026-64465",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64465"
},
{
"name": "CVE-2026-64313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64313"
},
{
"name": "CVE-2026-45932",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45932"
},
{
"name": "CVE-2026-72071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72071"
},
{
"name": "CVE-2026-63978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63978"
},
{
"name": "CVE-2026-52988",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52988"
},
{
"name": "CVE-2026-53157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53157"
},
{
"name": "CVE-2026-64112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64112"
},
{
"name": "CVE-2025-10263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10263"
},
{
"name": "CVE-2026-53135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53135"
},
{
"name": "CVE-2026-63853",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63853"
},
{
"name": "CVE-2026-64442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64442"
},
{
"name": "CVE-2026-64554",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64554"
},
{
"name": "CVE-2026-53333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53333"
},
{
"name": "CVE-2026-64477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64477"
},
{
"name": "CVE-2026-64463",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64463"
},
{
"name": "CVE-2026-64401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64401"
},
{
"name": "CVE-2026-72380",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72380"
},
{
"name": "CVE-2026-68159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68159"
},
{
"name": "CVE-2026-53188",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53188"
},
{
"name": "CVE-2026-43352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43352"
},
{
"name": "CVE-2026-53392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53392"
},
{
"name": "CVE-2026-64259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64259"
},
{
"name": "CVE-2026-64018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64018"
},
{
"name": "CVE-2026-74408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74408"
},
{
"name": "CVE-2026-74302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74302"
},
{
"name": "CVE-2026-23239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23239"
},
{
"name": "CVE-2026-64541",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64541"
},
{
"name": "CVE-2026-63916",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63916"
},
{
"name": "CVE-2026-64332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64332"
},
{
"name": "CVE-2026-53170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53170"
},
{
"name": "CVE-2026-53167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53167"
},
{
"name": "CVE-2026-64191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64191"
},
{
"name": "CVE-2026-72499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72499"
},
{
"name": "CVE-2026-64458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64458"
},
{
"name": "CVE-2026-64127",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64127"
},
{
"name": "CVE-2026-64476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64476"
},
{
"name": "CVE-2026-64378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64378"
},
{
"name": "CVE-2026-72323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72323"
},
{
"name": "CVE-2026-72065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72065"
},
{
"name": "CVE-2026-64318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64318"
},
{
"name": "CVE-2026-68137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68137"
},
{
"name": "CVE-2026-64300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64300"
},
{
"name": "CVE-2026-72398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72398"
},
{
"name": "CVE-2026-52908",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52908"
},
{
"name": "CVE-2026-63794",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63794"
},
{
"name": "CVE-2026-64394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64394"
},
{
"name": "CVE-2026-74398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74398"
},
{
"name": "CVE-2026-53237",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53237"
},
{
"name": "CVE-2026-80591",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80591"
},
{
"name": "CVE-2026-53186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53186"
},
{
"name": "CVE-2026-53340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53340"
},
{
"name": "CVE-2026-53182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53182"
},
{
"name": "CVE-2026-53177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53177"
},
{
"name": "CVE-2026-53208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53208"
},
{
"name": "CVE-2026-64055",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64055"
},
{
"name": "CVE-2026-53255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53255"
},
{
"name": "CVE-2026-53207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53207"
},
{
"name": "CVE-2026-64244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64244"
},
{
"name": "CVE-2025-38242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38242"
},
{
"name": "CVE-2026-53347",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53347"
},
{
"name": "CVE-2026-53187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53187"
},
{
"name": "CVE-2025-39862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39862"
},
{
"name": "CVE-2026-53160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53160"
},
{
"name": "CVE-2026-74384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74384"
},
{
"name": "CVE-2026-53245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53245"
},
{
"name": "CVE-2026-53195",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53195"
},
{
"name": "CVE-2026-64309",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64309"
},
{
"name": "CVE-2026-64173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64173"
},
{
"name": "CVE-2026-53043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53043"
},
{
"name": "CVE-2026-63824",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63824"
},
{
"name": "CVE-2026-53171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53171"
},
{
"name": "CVE-2026-63914",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63914"
},
{
"name": "CVE-2026-64556",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64556"
},
{
"name": "CVE-2026-63825",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63825"
},
{
"name": "CVE-2025-21693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21693"
},
{
"name": "CVE-2026-53164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53164"
},
{
"name": "CVE-2025-39789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39789"
},
{
"name": "CVE-2026-63874",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63874"
},
{
"name": "CVE-2025-38206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38206"
},
{
"name": "CVE-2026-53232",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53232"
},
{
"name": "CVE-2026-64435",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64435"
},
{
"name": "CVE-2025-22104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22104"
},
{
"name": "CVE-2026-64184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64184"
},
{
"name": "CVE-2026-68117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68117"
},
{
"name": "CVE-2026-64336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64336"
},
{
"name": "CVE-2026-74411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74411"
},
{
"name": "CVE-2026-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53148"
},
{
"name": "CVE-2025-68745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68745"
},
{
"name": "CVE-2026-53189",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53189"
},
{
"name": "CVE-2026-64352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64352"
},
{
"name": "CVE-2026-72318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72318"
},
{
"name": "CVE-2026-64555",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64555"
},
{
"name": "CVE-2026-64474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64474"
},
{
"name": "CVE-2026-64115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64115"
},
{
"name": "CVE-2026-64356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64356"
},
{
"name": "CVE-2026-63867",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63867"
},
{
"name": "CVE-2026-64586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64586"
},
{
"name": "CVE-2026-43048",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43048"
},
{
"name": "CVE-2026-53133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53133"
},
{
"name": "CVE-2026-64377",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64377"
},
{
"name": "CVE-2026-53204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53204"
},
{
"name": "CVE-2026-64346",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64346"
},
{
"name": "CVE-2026-53351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53351"
},
{
"name": "CVE-2026-31479",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31479"
},
{
"name": "CVE-2026-46266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46266"
},
{
"name": "CVE-2026-53024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53024"
},
{
"name": "CVE-2026-68209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68209"
},
{
"name": "CVE-2026-53344",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53344"
},
{
"name": "CVE-2026-53263",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53263"
},
{
"name": "CVE-2026-64160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64160"
},
{
"name": "CVE-2025-40074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40074"
},
{
"name": "CVE-2026-63945",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63945"
},
{
"name": "CVE-2025-68360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68360"
},
{
"name": "CVE-2026-63822",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63822"
},
{
"name": "CVE-2026-72329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72329"
},
{
"name": "CVE-2026-74310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74310"
},
{
"name": "CVE-2026-72041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72041"
},
{
"name": "CVE-2026-64187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64187"
},
{
"name": "CVE-2026-64342",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64342"
},
{
"name": "CVE-2025-40158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40158"
},
{
"name": "CVE-2026-64392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64392"
},
{
"name": "CVE-2026-64360",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64360"
},
{
"name": "CVE-2026-64096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64096"
},
{
"name": "CVE-2026-53118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53118"
},
{
"name": "CVE-2026-64478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64478"
},
{
"name": "CVE-2026-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68206"
},
{
"name": "CVE-2026-53152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53152"
},
{
"name": "CVE-2026-53356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53356"
},
{
"name": "CVE-2026-63799",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63799"
},
{
"name": "CVE-2026-64472",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64472"
},
{
"name": "CVE-2025-40168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40168"
},
{
"name": "CVE-2026-64335",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64335"
},
{
"name": "CVE-2026-53228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53228"
},
{
"name": "CVE-2026-63906",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63906"
},
{
"name": "CVE-2026-72399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72399"
},
{
"name": "CVE-2026-64301",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64301"
},
{
"name": "CVE-2026-64315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64315"
},
{
"name": "CVE-2026-64395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64395"
},
{
"name": "CVE-2026-64273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64273"
},
{
"name": "CVE-2026-74541",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74541"
},
{
"name": "CVE-2026-53259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53259"
},
{
"name": "CVE-2026-63828",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63828"
},
{
"name": "CVE-2025-37906",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37906"
},
{
"name": "CVE-2026-72226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72226"
},
{
"name": "CVE-2026-43126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43126"
},
{
"name": "CVE-2026-63820",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63820"
},
{
"name": "CVE-2026-64262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64262"
},
{
"name": "CVE-2026-23392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23392"
},
{
"name": "CVE-2026-31771",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31771"
},
{
"name": "CVE-2026-53336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53336"
},
{
"name": "CVE-2025-21985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21985"
},
{
"name": "CVE-2025-22109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22109"
},
{
"name": "CVE-2025-40040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40040"
},
{
"name": "CVE-2026-72348",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72348"
},
{
"name": "CVE-2025-23132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23132"
},
{
"name": "CVE-2026-64509",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64509"
},
{
"name": "CVE-2026-64117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64117"
},
{
"name": "CVE-2026-53194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53194"
},
{
"name": "CVE-2026-64084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64084"
},
{
"name": "CVE-2026-64307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64307"
},
{
"name": "CVE-2026-53242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53242"
},
{
"name": "CVE-2026-53248",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53248"
},
{
"name": "CVE-2024-56552",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56552"
},
{
"name": "CVE-2026-53341",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53341"
},
{
"name": "CVE-2026-52910",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52910"
},
{
"name": "CVE-2026-53206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53206"
},
{
"name": "CVE-2026-64339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64339"
},
{
"name": "CVE-2026-64108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64108"
},
{
"name": "CVE-2026-64529",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64529"
},
{
"name": "CVE-2026-53388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53388"
},
{
"name": "CVE-2026-63804",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63804"
},
{
"name": "CVE-2026-64305",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64305"
},
{
"name": "CVE-2025-39958",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39958"
},
{
"name": "CVE-2026-53212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53212"
},
{
"name": "CVE-2026-53137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53137"
},
{
"name": "CVE-2026-46054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46054"
},
{
"name": "CVE-2026-64400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64400"
},
{
"name": "CVE-2026-64381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64381"
},
{
"name": "CVE-2021-47378",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47378"
},
{
"name": "CVE-2026-64604",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64604"
},
{
"name": "CVE-2026-53393",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53393"
},
{
"name": "CVE-2026-53337",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53337"
},
{
"name": "CVE-2026-64597",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64597"
},
{
"name": "CVE-2026-63812",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63812"
},
{
"name": "CVE-2026-63887",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63887"
},
{
"name": "CVE-2026-53199",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53199"
},
{
"name": "CVE-2026-68136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68136"
},
{
"name": "CVE-2026-64496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64496"
},
{
"name": "CVE-2026-64251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64251"
},
{
"name": "CVE-2026-53025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53025"
},
{
"name": "CVE-2026-68144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68144"
},
{
"name": "CVE-2026-64113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64113"
},
{
"name": "CVE-2026-64387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64387"
},
{
"name": "CVE-2026-52938",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52938"
},
{
"name": "CVE-2026-64103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64103"
},
{
"name": "CVE-2026-68082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68082"
},
{
"name": "CVE-2026-64408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64408"
},
{
"name": "CVE-2026-68156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68156"
},
{
"name": "CVE-2026-72489",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72489"
},
{
"name": "CVE-2026-64136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64136"
},
{
"name": "CVE-2026-53165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53165"
},
{
"name": "CVE-2026-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53197"
},
{
"name": "CVE-2026-64481",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64481"
},
{
"name": "CVE-2026-53258",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53258"
},
{
"name": "CVE-2026-64316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64316"
},
{
"name": "CVE-2026-64174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64174"
},
{
"name": "CVE-2026-64000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64000"
},
{
"name": "CVE-2026-64417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64417"
},
{
"name": "CVE-2026-53268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53268"
},
{
"name": "CVE-2026-64457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64457"
},
{
"name": "CVE-2026-63819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63819"
},
{
"name": "CVE-2026-53241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53241"
},
{
"name": "CVE-2026-53223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53223"
},
{
"name": "CVE-2026-64423",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64423"
},
{
"name": "CVE-2026-31414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31414"
},
{
"name": "CVE-2026-53005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53005"
},
{
"name": "CVE-2026-64034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64034"
},
{
"name": "CVE-2026-64443",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64443"
},
{
"name": "CVE-2026-53159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53159"
},
{
"name": "CVE-2026-64588",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64588"
},
{
"name": "CVE-2026-64093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64093"
},
{
"name": "CVE-2026-63868",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63868"
},
{
"name": "CVE-2022-50401",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50401"
},
{
"name": "CVE-2026-64269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64269"
},
{
"name": "CVE-2026-53267",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53267"
},
{
"name": "CVE-2026-72296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72296"
},
{
"name": "CVE-2026-52912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52912"
},
{
"name": "CVE-2024-58098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58098"
},
{
"name": "CVE-2026-64482",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64482"
},
{
"name": "CVE-2026-64218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64218"
},
{
"name": "CVE-2026-64495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64495"
},
{
"name": "CVE-2026-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53221"
},
{
"name": "CVE-2026-63811",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63811"
},
{
"name": "CVE-2026-64282",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64282"
},
{
"name": "CVE-2026-53275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53275"
},
{
"name": "CVE-2026-64366",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64366"
},
{
"name": "CVE-2026-64594",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64594"
},
{
"name": "CVE-2026-64278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64278"
},
{
"name": "CVE-2025-38636",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38636"
},
{
"name": "CVE-2026-64396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64396"
},
{
"name": "CVE-2026-53203",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53203"
},
{
"name": "CVE-2026-53269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53269"
},
{
"name": "CVE-2026-64479",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64479"
},
{
"name": "CVE-2026-64324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64324"
},
{
"name": "CVE-2026-64329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64329"
},
{
"name": "CVE-2026-64434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64434"
},
{
"name": "CVE-2026-64373",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64373"
},
{
"name": "CVE-2026-64219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64219"
},
{
"name": "CVE-2026-64277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64277"
},
{
"name": "CVE-2026-53357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53357"
},
{
"name": "CVE-2026-46324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46324"
},
{
"name": "CVE-2026-64126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64126"
},
{
"name": "CVE-2026-53136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53136"
},
{
"name": "CVE-2026-64503",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64503"
},
{
"name": "CVE-2026-64562",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64562"
},
{
"name": "CVE-2026-64168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64168"
},
{
"name": "CVE-2026-53216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53216"
},
{
"name": "CVE-2026-74350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74350"
},
{
"name": "CVE-2026-72496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72496"
},
{
"name": "CVE-2026-53153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53153"
},
{
"name": "CVE-2026-64291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64291"
},
{
"name": "CVE-2026-53226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53226"
},
{
"name": "CVE-2025-40203",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40203"
},
{
"name": "CVE-2026-53089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53089"
},
{
"name": "CVE-2026-63809",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63809"
},
{
"name": "CVE-2026-43172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43172"
},
{
"name": "CVE-2026-53253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53253"
},
{
"name": "CVE-2026-68161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68161"
},
{
"name": "CVE-2026-53250",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53250"
},
{
"name": "CVE-2026-64453",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64453"
},
{
"name": "CVE-2026-53394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53394"
},
{
"name": "CVE-2026-64436",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64436"
},
{
"name": "CVE-2026-64403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64403"
},
{
"name": "CVE-2026-52948",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52948"
},
{
"name": "CVE-2026-64121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64121"
},
{
"name": "CVE-2026-63836",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63836"
},
{
"name": "CVE-2026-63814",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63814"
},
{
"name": "CVE-2026-53252",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53252"
},
{
"name": "CVE-2026-64412",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64412"
},
{
"name": "CVE-2026-64284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64284"
},
{
"name": "CVE-2026-53355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53355"
},
{
"name": "CVE-2026-43029",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43029"
},
{
"name": "CVE-2026-74556",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74556"
},
{
"name": "CVE-2026-64188",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64188"
},
{
"name": "CVE-2026-64491",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64491"
},
{
"name": "CVE-2026-74287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74287"
},
{
"name": "CVE-2026-72454",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72454"
},
{
"name": "CVE-2026-64144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64144"
},
{
"name": "CVE-2026-64487",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64487"
},
{
"name": "CVE-2026-64391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64391"
},
{
"name": "CVE-2025-40170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40170"
},
{
"name": "CVE-2026-64303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64303"
},
{
"name": "CVE-2026-64086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64086"
},
{
"name": "CVE-2026-45944",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45944"
},
{
"name": "CVE-2026-64429",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64429"
},
{
"name": "CVE-2024-57857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57857"
},
{
"name": "CVE-2026-64344",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64344"
},
{
"name": "CVE-2026-53134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53134"
},
{
"name": "CVE-2026-63831",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63831"
},
{
"name": "CVE-2026-64286",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64286"
},
{
"name": "CVE-2026-64292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64292"
},
{
"name": "CVE-2026-53359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53359"
},
{
"name": "CVE-2026-64029",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64029"
},
{
"name": "CVE-2026-63834",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63834"
},
{
"name": "CVE-2026-52986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52986"
},
{
"name": "CVE-2026-63919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63919"
},
{
"name": "CVE-2026-68124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68124"
},
{
"name": "CVE-2026-68381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68381"
},
{
"name": "CVE-2026-64350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64350"
},
{
"name": "CVE-2026-64321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64321"
},
{
"name": "CVE-2026-72473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72473"
},
{
"name": "CVE-2026-64111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64111"
},
{
"name": "CVE-2026-64447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64447"
},
{
"name": "CVE-2026-53256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53256"
},
{
"name": "CVE-2026-72014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72014"
},
{
"name": "CVE-2026-64411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64411"
},
{
"name": "CVE-2026-53235",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53235"
},
{
"name": "CVE-2024-44964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44964"
},
{
"name": "CVE-2026-74279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74279"
},
{
"name": "CVE-2026-53129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53129"
},
{
"name": "CVE-2026-53396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53396"
},
{
"name": "CVE-2026-43353",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43353"
},
{
"name": "CVE-2026-64137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64137"
},
{
"name": "CVE-2026-43071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43071"
},
{
"name": "CVE-2026-68431",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68431"
},
{
"name": "CVE-2026-43303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43303"
},
{
"name": "CVE-2026-53045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53045"
},
{
"name": "CVE-2026-72098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72098"
},
{
"name": "CVE-2025-37876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37876"
},
{
"name": "CVE-2024-58089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58089"
},
{
"name": "CVE-2026-64334",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64334"
},
{
"name": "CVE-2026-53384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53384"
},
{
"name": "CVE-2026-53155",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53155"
},
{
"name": "CVE-2026-74495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74495"
},
{
"name": "CVE-2026-64183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64183"
},
{
"name": "CVE-2026-64448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64448"
},
{
"name": "CVE-2026-72111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72111"
},
{
"name": "CVE-2026-74407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74407"
},
{
"name": "CVE-2026-74280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74280"
},
{
"name": "CVE-2026-72221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72221"
},
{
"name": "CVE-2026-72289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72289"
},
{
"name": "CVE-2026-72251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72251"
},
{
"name": "CVE-2026-64347",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64347"
},
{
"name": "CVE-2026-63826",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63826"
},
{
"name": "CVE-2026-53120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53120"
},
{
"name": "CVE-2026-64393",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64393"
},
{
"name": "CVE-2026-64134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64134"
},
{
"name": "CVE-2026-64466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64466"
},
{
"name": "CVE-2026-64419",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64419"
},
{
"name": "CVE-2026-23393",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23393"
},
{
"name": "CVE-2026-53145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53145"
},
{
"name": "CVE-2026-53270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53270"
},
{
"name": "CVE-2026-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53198"
},
{
"name": "CVE-2026-64382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64382"
},
{
"name": "CVE-2026-64589",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64589"
},
{
"name": "CVE-2026-63946",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63946"
},
{
"name": "CVE-2026-53240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53240"
},
{
"name": "CVE-2026-64372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64372"
},
{
"name": "CVE-2026-64490",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64490"
},
{
"name": "CVE-2026-52909",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52909"
},
{
"name": "CVE-2026-68300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68300"
},
{
"name": "CVE-2026-63922",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63922"
},
{
"name": "CVE-2026-64283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64283"
},
{
"name": "CVE-2026-53395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53395"
},
{
"name": "CVE-2026-43263",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43263"
},
{
"name": "CVE-2026-64444",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64444"
},
{
"name": "CVE-2026-72126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72126"
},
{
"name": "CVE-2026-68229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68229"
},
{
"name": "CVE-2026-64225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64225"
},
{
"name": "CVE-2026-64331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64331"
},
{
"name": "CVE-2026-64511",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64511"
},
{
"name": "CVE-2026-64032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64032"
},
{
"name": "CVE-2026-64361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64361"
},
{
"name": "CVE-2026-64182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64182"
},
{
"name": "CVE-2026-53264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53264"
},
{
"name": "CVE-2026-53142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53142"
},
{
"name": "CVE-2026-68152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68152"
},
{
"name": "CVE-2026-64369",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64369"
},
{
"name": "CVE-2025-37776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37776"
},
{
"name": "CVE-2026-63944",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63944"
},
{
"name": "CVE-2026-53273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53273"
},
{
"name": "CVE-2025-39896",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39896"
},
{
"name": "CVE-2026-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53184"
},
{
"name": "CVE-2026-31560",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31560"
},
{
"name": "CVE-2026-64056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64056"
},
{
"name": "CVE-2026-43101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43101"
},
{
"name": "CVE-2026-64265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64265"
},
{
"name": "CVE-2026-64494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64494"
},
{
"name": "CVE-2026-74268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74268"
},
{
"name": "CVE-2026-43042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43042"
},
{
"name": "CVE-2026-72451",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72451"
},
{
"name": "CVE-2026-74475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74475"
},
{
"name": "CVE-2026-53144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53144"
},
{
"name": "CVE-2026-64033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64033"
},
{
"name": "CVE-2026-63893",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63893"
},
{
"name": "CVE-2026-68158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68158"
},
{
"name": "CVE-2026-53385",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53385"
},
{
"name": "CVE-2026-53246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53246"
},
{
"name": "CVE-2026-64245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64245"
},
{
"name": "CVE-2026-53326",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53326"
},
{
"name": "CVE-2026-63823",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63823"
},
{
"name": "CVE-2026-46175",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46175"
},
{
"name": "CVE-2026-53325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53325"
},
{
"name": "CVE-2026-64354",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64354"
},
{
"name": "CVE-2026-64206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64206"
},
{
"name": "CVE-2026-64530",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64530"
},
{
"name": "CVE-2026-64015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64015"
},
{
"name": "CVE-2026-64294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64294"
},
{
"name": "CVE-2024-58241",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58241"
},
{
"name": "CVE-2026-64288",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64288"
},
{
"name": "CVE-2026-64285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64285"
},
{
"name": "CVE-2026-31657",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31657"
},
{
"name": "CVE-2025-22108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22108"
},
{
"name": "CVE-2026-68470",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68470"
},
{
"name": "CVE-2026-53363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53363"
},
{
"name": "CVE-2026-74436",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74436"
},
{
"name": "CVE-2026-52991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52991"
},
{
"name": "CVE-2026-63808",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63808"
},
{
"name": "CVE-2025-40025",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40025"
},
{
"name": "CVE-2026-53191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53191"
},
{
"name": "CVE-2026-72217",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72217"
},
{
"name": "CVE-2026-64493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64493"
},
{
"name": "CVE-2026-52940",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52940"
},
{
"name": "CVE-2026-53358",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53358"
},
{
"name": "CVE-2026-64535",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64535"
},
{
"name": "CVE-2026-53352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53352"
},
{
"name": "CVE-2026-68198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68198"
},
{
"name": "CVE-2026-64416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64416"
},
{
"name": "CVE-2026-72234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72234"
},
{
"name": "CVE-2026-64247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64247"
},
{
"name": "CVE-2026-64379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64379"
},
{
"name": "CVE-2026-53254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53254"
},
{
"name": "CVE-2026-68123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68123"
},
{
"name": "CVE-2026-53078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53078"
},
{
"name": "CVE-2025-38498",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38498"
},
{
"name": "CVE-2026-23327",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23327"
},
{
"name": "CVE-2026-64420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64420"
},
{
"name": "CVE-2024-58100",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58100"
},
{
"name": "CVE-2026-64138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64138"
},
{
"name": "CVE-2026-64153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64153"
},
{
"name": "CVE-2026-53180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53180"
},
{
"name": "CVE-2026-53238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53238"
},
{
"name": "CVE-2026-64205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64205"
},
{
"name": "CVE-2026-53284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53284"
},
{
"name": "CVE-2026-52921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52921"
},
{
"name": "CVE-2026-64548",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64548"
},
{
"name": "CVE-2026-53281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53281"
},
{
"name": "CVE-2024-44932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44932"
},
{
"name": "CVE-2026-64118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64118"
},
{
"name": "CVE-2026-68162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68162"
},
{
"name": "CVE-2026-64325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64325"
},
{
"name": "CVE-2026-74427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74427"
},
{
"name": "CVE-2026-53213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53213"
},
{
"name": "CVE-2026-64596",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64596"
},
{
"name": "CVE-2026-53387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53387"
},
{
"name": "CVE-2026-64384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64384"
},
{
"name": "CVE-2026-68084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68084"
},
{
"name": "CVE-2026-64406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64406"
},
{
"name": "CVE-2026-63912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63912"
},
{
"name": "CVE-2026-64425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64425"
},
{
"name": "CVE-2026-64600",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64600"
},
{
"name": "CVE-2026-74406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74406"
},
{
"name": "CVE-2026-52930",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52930"
},
{
"name": "CVE-2026-64064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64064"
},
{
"name": "CVE-2026-64116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64116"
},
{
"name": "CVE-2026-64312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64312"
},
{
"name": "CVE-2026-74480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74480"
},
{
"name": "CVE-2026-46275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46275"
},
{
"name": "CVE-2026-68460",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68460"
},
{
"name": "CVE-2026-53265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53265"
},
{
"name": "CVE-2026-64428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64428"
},
{
"name": "CVE-2026-64505",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64505"
},
{
"name": "CVE-2026-64426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64426"
},
{
"name": "CVE-2026-64507",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64507"
},
{
"name": "CVE-2026-53366",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53366"
},
{
"name": "CVE-2026-64087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64087"
},
{
"name": "CVE-2026-45850",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45850"
},
{
"name": "CVE-2026-64499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64499"
},
{
"name": "CVE-2024-56591",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56591"
},
{
"name": "CVE-2026-31630",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31630"
},
{
"name": "CVE-2026-74584",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74584"
},
{
"name": "CVE-2026-53154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53154"
},
{
"name": "CVE-2026-64358",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64358"
},
{
"name": "CVE-2026-64355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64355"
},
{
"name": "CVE-2026-72069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72069"
},
{
"name": "CVE-2026-64290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64290"
},
{
"name": "CVE-2026-64185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64185"
},
{
"name": "CVE-2026-64422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64422"
},
{
"name": "CVE-2026-72020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72020"
},
{
"name": "CVE-2026-43116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43116"
},
{
"name": "CVE-2026-53196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53196"
},
{
"name": "CVE-2026-64340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64340"
},
{
"name": "CVE-2025-38204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38204"
},
{
"name": "CVE-2026-64092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64092"
},
{
"name": "CVE-2026-53000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53000"
},
{
"name": "CVE-2026-64007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64007"
},
{
"name": "CVE-2026-64450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64450"
},
{
"name": "CVE-2026-53156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53156"
},
{
"name": "CVE-2026-64484",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64484"
},
{
"name": "CVE-2026-64298",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64298"
},
{
"name": "CVE-2025-39677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39677"
},
{
"name": "CVE-2026-64207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64207"
},
{
"name": "CVE-2026-63994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63994"
},
{
"name": "CVE-2026-64114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64114"
},
{
"name": "CVE-2026-64390",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64390"
},
{
"name": "CVE-2026-53390",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53390"
},
{
"name": "CVE-2026-74255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74255"
},
{
"name": "CVE-2026-72191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72191"
},
{
"name": "CVE-2026-64266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64266"
},
{
"name": "CVE-2026-53211",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53211"
},
{
"name": "CVE-2026-64088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64088"
},
{
"name": "CVE-2026-64073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64073"
},
{
"name": "CVE-2026-64441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64441"
},
{
"name": "CVE-2025-21687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21687"
},
{
"name": "CVE-2026-53162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53162"
},
{
"name": "CVE-2026-53343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53343"
},
{
"name": "CVE-2026-74269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74269"
},
{
"name": "CVE-2026-52926",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52926"
},
{
"name": "CVE-2026-72124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72124"
},
{
"name": "CVE-2026-63829",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63829"
},
{
"name": "CVE-2026-72192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72192"
},
{
"name": "CVE-2026-72288",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72288"
},
{
"name": "CVE-2026-64135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64135"
},
{
"name": "CVE-2026-64440",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64440"
},
{
"name": "CVE-2026-63803",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63803"
},
{
"name": "CVE-2026-64564",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64564"
},
{
"name": "CVE-2026-52917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52917"
},
{
"name": "CVE-2026-64601",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64601"
},
{
"name": "CVE-2026-53261",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53261"
},
{
"name": "CVE-2026-72085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72085"
},
{
"name": "CVE-2026-52982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52982"
},
{
"name": "CVE-2026-64011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64011"
},
{
"name": "CVE-2026-64359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64359"
},
{
"name": "CVE-2026-64317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64317"
},
{
"name": "CVE-2026-53328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53328"
},
{
"name": "CVE-2026-68154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68154"
},
{
"name": "CVE-2026-63802",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63802"
},
{
"name": "CVE-2026-63869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63869"
}
],
"initial_release_date": "2026-09-18T00:00:00",
"last_revision_date": "2026-09-18T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1203",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-09-18T00:00:00.000000"
}
],
"risks": [
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Elles permettent \u00e0 un attaquant de provoquer un probl\u00e8me de s\u00e9curit\u00e9 non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2026-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8726-2",
"url": "https://ubuntu.com/security/notices/USN-8726-2"
},
{
"published_at": "2026-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8761-2",
"url": "https://ubuntu.com/security/notices/USN-8761-2"
},
{
"published_at": "2026-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8730-3",
"url": "https://ubuntu.com/security/notices/USN-8730-3"
},
{
"published_at": "2026-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8714-3",
"url": "https://ubuntu.com/security/notices/USN-8714-3"
},
{
"published_at": "2026-09-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8730-2",
"url": "https://ubuntu.com/security/notices/USN-8730-2"
},
{
"published_at": "2026-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8725-2",
"url": "https://ubuntu.com/security/notices/USN-8725-2"
},
{
"published_at": "2026-09-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8760-1",
"url": "https://ubuntu.com/security/notices/USN-8760-1"
},
{
"published_at": "2026-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8781-1",
"url": "https://ubuntu.com/security/notices/USN-8781-1"
},
{
"published_at": "2026-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8729-2",
"url": "https://ubuntu.com/security/notices/USN-8729-2"
},
{
"published_at": "2026-09-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8761-1",
"url": "https://ubuntu.com/security/notices/USN-8761-1"
},
{
"published_at": "2026-09-18",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8715-2",
"url": "https://ubuntu.com/security/notices/USN-8715-2"
}
]
}
CERTFR-2026-AVI-1204
Vulnerability from certfr_avis - Published: 2026-09-18 - Updated: 2026-09-18
De multiples vulnérabilités ont été découvertes dans le noyau Linux de Red Hat. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server - AUS 8.6 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 10.0 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.8 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian 8 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.2 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems 8 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.8 aarch64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 9.8 aarch64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 10.2 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Update Support 10.2 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 8 x86_64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for IBM z Systems 9 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.8 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.2 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 10 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.4 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Real Time 8 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Update Support 10.0 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - 4 years of updates 10.0 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.4 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.2 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 9 aarch64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 10.0 ppc64le | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for x86_64 10 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.4 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Update Support 10.2 aarch64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 9.8 x86_64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for Power, little endian 9 ppc64le | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for IBM z Systems 10 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - 4 years of support 10.2 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - 4 years of support 10.0 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 10.2 x86_64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 9.8 ppc64le | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for ARM 64 9 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 8.10 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.4 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.8 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.4 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.2 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 8.10 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.4 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 8 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 10 aarch64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for ARM 64 8 aarch64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 10.2 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Update Support 10.0 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 10.2 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.4 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Real Time for NFV 8 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server - AUS 9.4 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.8 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.8 x86_64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 10.2 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 10.2 ppc64le | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for x86_64 8 x86_64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 10.0 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.2 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 8.10 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems 9 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - 4 years of updates 10.2 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 10.0 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.8 s390x | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server - AUS 9.2 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 9.8 s390x | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for ARM 64 10 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.4 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 10.2 s390x | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 10.0 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.8 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Update Support 10.2 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle Long Life 8.6 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Update Support 9.8 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 10.2 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 8.10 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian 9 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Update Support 9.8 aarch64 | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for Power, little endian 8 ppc64le | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 10.2 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.2 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 10.2 s390x | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.2 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for IBM z Systems 10 s390x | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for x86_64 9 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 - Extended Update Support 9.8 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for x86_64 9 x86_64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for Power, little endian 10 ppc64le | ||
| Red Hat | Red Hat CodeReady Linux Builder | Red Hat CodeReady Linux Builder for Power, little endian 10 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 10.2 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux Server | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.2 ppc64le | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 10.0 aarch64 | ||
| Red Hat | Red Hat Enterprise Linux | Red Hat Enterprise Linux for ARM 64 - Extended Update Support 10.0 aarch64 |
| Title | Publication Time | Tags | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Red Hat Enterprise Linux Server - AUS 8.6 x86_64",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 10.0 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.8 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian 8 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.2 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems 8 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.8 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 9.8 aarch64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 10.2 ppc64le",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support 10.2 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 8 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems 9 s390x",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.8 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.2 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 10 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.4 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Real Time 8 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support 10.0 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - 4 years of updates 10.0 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.4 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.2 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 9 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 10.0 ppc64le",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 10 x86_64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.4 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Update Support 10.2 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 9.8 x86_64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian 9 ppc64le",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems 10 s390x",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - 4 years of support 10.2 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - 4 years of support 10.0 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 10.2 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 9.8 ppc64le",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 9 aarch64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 8.10 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.4 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.8 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.4 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.2 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 8.10 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.4 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 8 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 10 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 8 aarch64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 10.2 s390x",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Update Support 10.0 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 10.2 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.4 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Real Time for NFV 8 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 9.4 x86_64",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.8 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.8 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 10.2 aarch64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 10.2 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 8 x86_64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 10.0 aarch64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.2 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 8.10 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems 9 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - 4 years of updates 10.2 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 10.0 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.8 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 9.2 x86_64",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 9.8 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 10 aarch64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.4 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 10.2 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 10.0 x86_64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.8 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Update Support 10.2 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle Long Life 8.6 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Update Support 9.8 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 10.2 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 8.10 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian 9 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Update Support 9.8 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian 8 ppc64le",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 10.2 x86_64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.2 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 10.2 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.2 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems 10 s390x",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 9 x86_64",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support 9.8 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 9 x86_64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian 10 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian 10 ppc64le",
"product": {
"name": "Red Hat CodeReady Linux Builder",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 10.2 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.2 ppc64le",
"product": {
"name": "Red Hat Enterprise Linux Server",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 10.0 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Update Support 10.0 aarch64",
"product": {
"name": "Red Hat Enterprise Linux",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2026-53192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53192"
},
{
"name": "CVE-2026-31539",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31539"
},
{
"name": "CVE-2026-63923",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63923"
},
{
"name": "CVE-2026-63921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63921"
},
{
"name": "CVE-2026-52947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52947"
},
{
"name": "CVE-2026-64268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64268"
},
{
"name": "CVE-2026-53193",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53193"
},
{
"name": "CVE-2026-64414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64414"
},
{
"name": "CVE-2026-31656",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31656"
},
{
"name": "CVE-2026-72298",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72298"
},
{
"name": "CVE-2026-63886",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63886"
},
{
"name": "CVE-2026-43339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43339"
},
{
"name": "CVE-2026-64176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64176"
},
{
"name": "CVE-2025-40026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40026"
},
{
"name": "CVE-2026-68128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68128"
},
{
"name": "CVE-2026-52924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52924"
},
{
"name": "CVE-2026-43248",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43248"
},
{
"name": "CVE-2026-68294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68294"
},
{
"name": "CVE-2026-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53239"
},
{
"name": "CVE-2026-63888",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63888"
},
{
"name": "CVE-2026-64304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64304"
},
{
"name": "CVE-2026-64438",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64438"
},
{
"name": "CVE-2026-53071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53071"
},
{
"name": "CVE-2024-58007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58007"
},
{
"name": "CVE-2026-53006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53006"
},
{
"name": "CVE-2026-68363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68363"
},
{
"name": "CVE-2026-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53176"
},
{
"name": "CVE-2026-31663",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31663"
},
{
"name": "CVE-2026-23172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23172"
},
{
"name": "CVE-2026-68426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68426"
},
{
"name": "CVE-2026-31566",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31566"
},
{
"name": "CVE-2026-63917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63917"
},
{
"name": "CVE-2026-23466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23466"
},
{
"name": "CVE-2026-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53131"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-53361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53361"
},
{
"name": "CVE-2026-64456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64456"
},
{
"name": "CVE-2024-53161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53161"
},
{
"name": "CVE-2026-52971",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52971"
},
{
"name": "CVE-2026-68143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68143"
},
{
"name": "CVE-2026-53182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53182"
},
{
"name": "CVE-2026-46150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46150"
},
{
"name": "CVE-2025-68745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68745"
},
{
"name": "CVE-2026-45998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45998"
},
{
"name": "CVE-2026-31479",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31479"
},
{
"name": "CVE-2026-46266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46266"
},
{
"name": "CVE-2026-68264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68264"
},
{
"name": "CVE-2026-72102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72102"
},
{
"name": "CVE-2026-53228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53228"
},
{
"name": "CVE-2026-64117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64117"
},
{
"name": "CVE-2026-43370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43370"
},
{
"name": "CVE-2026-46054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46054"
},
{
"name": "CVE-2026-64175",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64175"
},
{
"name": "CVE-2026-63887",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63887"
},
{
"name": "CVE-2026-64387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64387"
},
{
"name": "CVE-2026-53268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53268"
},
{
"name": "CVE-2026-53223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53223"
},
{
"name": "CVE-2025-40149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40149"
},
{
"name": "CVE-2026-68200",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68200"
},
{
"name": "CVE-2026-43133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43133"
},
{
"name": "CVE-2026-53275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53275"
},
{
"name": "CVE-2026-52920",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52920"
},
{
"name": "CVE-2026-46056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46056"
},
{
"name": "CVE-2026-74556",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74556"
},
{
"name": "CVE-2026-46149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46149"
},
{
"name": "CVE-2026-64029",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64029"
},
{
"name": "CVE-2026-53016",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53016"
},
{
"name": "CVE-2026-63919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63919"
},
{
"name": "CVE-2026-72045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72045"
},
{
"name": "CVE-2026-64111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64111"
},
{
"name": "CVE-2026-72098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72098"
},
{
"name": "CVE-2026-46306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46306"
},
{
"name": "CVE-2026-43233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43233"
},
{
"name": "CVE-2026-43114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43114"
},
{
"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-64530",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64530"
},
{
"name": "CVE-2026-64015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64015"
},
{
"name": "CVE-2025-71127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71127"
},
{
"name": "CVE-2026-74480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74480"
},
{
"name": "CVE-2026-63889",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63889"
},
{
"name": "CVE-2026-52933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52933"
},
{
"name": "CVE-2026-53196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53196"
},
{
"name": "CVE-2026-53000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53000"
},
{
"name": "CVE-2026-43368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43368"
},
{
"name": "CVE-2026-64002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64002"
},
{
"name": "CVE-2026-63802",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63802"
},
{
"name": "CVE-2026-63869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63869"
}
],
"initial_release_date": "2026-09-18T00:00:00",
"last_revision_date": "2026-09-18T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1204",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-09-18T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Ex\u00e9cution de code arbitraire"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de Red Hat. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de Red Hat",
"vendor_advisories": [
{
"published_at": "2026-09-15",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:67469",
"url": "https://access.redhat.com/errata/RHSA-2026:67469"
},
{
"published_at": "2026-09-15",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:67468",
"url": "https://access.redhat.com/errata/RHSA-2026:67468"
},
{
"published_at": "2026-09-16",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:68100",
"url": "https://access.redhat.com/errata/RHSA-2026:68100"
},
{
"published_at": "2026-09-17",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:68507",
"url": "https://access.redhat.com/errata/RHSA-2026:68507"
},
{
"published_at": "2026-09-15",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:67471",
"url": "https://access.redhat.com/errata/RHSA-2026:67471"
},
{
"published_at": "2026-09-16",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:68131",
"url": "https://access.redhat.com/errata/RHSA-2026:68131"
},
{
"published_at": "2026-09-16",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:67723",
"url": "https://access.redhat.com/errata/RHSA-2026:67723"
},
{
"published_at": "2026-09-17",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:68532",
"url": "https://access.redhat.com/errata/RHSA-2026:68532"
},
{
"published_at": "2026-09-14",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:67114",
"url": "https://access.redhat.com/errata/RHSA-2026:67114"
},
{
"published_at": "2026-09-14",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:67277",
"url": "https://access.redhat.com/errata/RHSA-2026:67277"
},
{
"published_at": "2026-09-15",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:67470",
"url": "https://access.redhat.com/errata/RHSA-2026:67470"
}
]
}
FKIE_CVE-2026-31663
Vulnerability from fkie_nvd - Published: 2026-04-24 15:16 - Updated: 2026-09-18 13:177.0 (High) - CVSS:3.1/
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 4.15 | |
| 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/ipv4/xfrm4_input.c",
"net/ipv6/xfrm6_input.c",
"net/xfrm/xfrm_input.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4236c30b437b80f673b9e08c8fae38b8d471ac9e",
"status": "affected",
"version": "acf568ee859f098279eadf551612f103afdacb4e",
"versionType": "git"
},
{
"lessThan": "0f451b43c88bf2b9c038b414be580efee42e031b",
"status": "affected",
"version": "acf568ee859f098279eadf551612f103afdacb4e",
"versionType": "git"
},
{
"lessThan": "5002beda5cac69d522dc54da0d5d463ed9c963d2",
"status": "affected",
"version": "acf568ee859f098279eadf551612f103afdacb4e",
"versionType": "git"
},
{
"lessThan": "1c428b03840094410c5fb6a5db30640486bbbfcb",
"status": "affected",
"version": "acf568ee859f098279eadf551612f103afdacb4e",
"versionType": "git"
},
{
"status": "affected",
"version": "69895c5ea0ca2e8d7de1e6d36965d0ab9730787f",
"versionType": "git"
},
{
"status": "affected",
"version": "833760100588acfb267dac4d6a02ab9931237739",
"versionType": "git"
},
{
"status": "affected",
"version": "e095ecaec6d94aa2156cceb98a85d409b51190f3",
"versionType": "git"
},
{
"lessThan": "3.3",
"status": "affected",
"version": "3.2.100",
"versionType": "semver"
},
{
"lessThan": "3.17",
"status": "affected",
"version": "3.16.55",
"versionType": "semver"
},
{
"lessThan": "4.15",
"status": "affected",
"version": "4.14.24",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/ipv4/xfrm4_input.c",
"net/ipv6/xfrm6_input.c",
"net/xfrm/xfrm_input.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.15"
},
{
"lessThan": "4.15",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.94",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.23",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.13",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:10.2"
],
"defaultStatus": "affected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 10",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "0:6.12.0-211.55.1.el10_2",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:enterprise_linux:8::nfv"
],
"defaultStatus": "affected",
"packageName": "kernel-rt",
"product": "Red Hat Enterprise Linux 8",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "0:4.18.0-553.164.1.rt7.505.el8_10",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:8"
],
"defaultStatus": "affected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 8",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "0:4.18.0-553.164.1.el8_10",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:enterprise_linux:9",
"cpe:/o:redhat:enterprise_linux:9"
],
"defaultStatus": "affected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 9",
"vendor": "Red Hat",
"versions": [
{
"lessThan": "*",
"status": "unaffected",
"version": "0:5.14.0-687.49.1.el9_8",
"versionType": "rpm"
}
]
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:6"
],
"defaultStatus": "unaffected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 6",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:7"
],
"defaultStatus": "affected",
"packageName": "kernel",
"product": "Red Hat Enterprise Linux 7",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:7"
],
"defaultStatus": "affected",
"packageName": "kernel-rt",
"product": "Red Hat Enterprise Linux 7",
"vendor": "Red Hat"
},
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/o:redhat:enterprise_linux:9"
],
"defaultStatus": "unaffected",
"packageName": "kernel-rt",
"product": "Red Hat Enterprise Linux 9",
"vendor": "Red Hat"
}
],
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6B10F87F-6387-4CE3-9159-D77EB163C9AD",
"versionEndExcluding": "3.3",
"versionStartIncluding": "3.2.100",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C9F9D919-846F-4FDC-882F-B49219EA19E9",
"versionEndExcluding": "3.17",
"versionStartIncluding": "3.16.55",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4C6AA567-92EC-46CF-9ED1-2B04B2B29BFB",
"versionEndExcluding": "4.15",
"versionStartIncluding": "4.14.24",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "45125EC8-B49D-48DD-92B9-2E4D1295531E",
"versionEndExcluding": "6.18.23",
"versionStartIncluding": "4.15.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "1490EF9B-9080-481C-8D22-1306AAE664E4",
"versionEndExcluding": "6.19.13",
"versionStartIncluding": "6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:4.15:-:*:*:*:*:*:*",
"matchCriteriaId": "3B4D39AF-668B-442B-8085-639A6D4FA5AC",
"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\nxfrm: hold dev ref until after transport_finish NF_HOOK\n\nAfter async crypto completes, xfrm_input_resume() calls dev_put()\nimmediately on re-entry before the skb reaches transport_finish.\nThe skb-\u003edev pointer is then used inside NF_HOOK and its okfn,\nwhich can race with device teardown.\n\nRemove the dev_put from the async resumption entry and instead\ndrop the reference after the NF_HOOK call in transport_finish,\nusing a saved device pointer since NF_HOOK may consume the skb.\nThis covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip\nthe okfn.\n\nFor non-transport exits (decaps, gro, drop) and secondary\nasync return points, release the reference inline when\nasync is set."
}
],
"id": "CVE-2026-31663",
"lastModified": "2026-09-18T13:17:45.590",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.0,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.0,
"impactScore": 5.9,
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"type": "Secondary"
}
]
},
"published": "2026-04-24T15:16:45.947",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0f451b43c88bf2b9c038b414be580efee42e031b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1c428b03840094410c5fb6a5db30640486bbbfcb"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4236c30b437b80f673b9e08c8fae38b8d471ac9e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5002beda5cac69d522dc54da0d5d463ed9c963d2"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://access.redhat.com/errata/RHSA-2026:67471"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://access.redhat.com/errata/RHSA-2026:68531"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://access.redhat.com/errata/RHSA-2026:68532"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://access.redhat.com/errata/RHSA-2026:68570"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://access.redhat.com/security/cve/CVE-2026-31663"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2461462"
},
{
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-31663.json"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-826"
}
],
"source": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"type": "Secondary"
}
]
}
GHSA-V4M9-VRGR-8XM2
Vulnerability from github – Published: 2026-04-24 15:32 – Updated: 2026-09-18 15:31In the Linux kernel, the following vulnerability has been resolved:
xfrm: hold dev ref until after transport_finish NF_HOOK
After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown.
Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn.
For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.
{
"affected": [],
"aliases": [
"CVE-2026-31663"
],
"database_specific": {
"cwe_ids": [
"CWE-826"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-24T15:16:45Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: hold dev ref until after transport_finish NF_HOOK\n\nAfter async crypto completes, xfrm_input_resume() calls dev_put()\nimmediately on re-entry before the skb reaches transport_finish.\nThe skb-\u003edev pointer is then used inside NF_HOOK and its okfn,\nwhich can race with device teardown.\n\nRemove the dev_put from the async resumption entry and instead\ndrop the reference after the NF_HOOK call in transport_finish,\nusing a saved device pointer since NF_HOOK may consume the skb.\nThis covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip\nthe okfn.\n\nFor non-transport exits (decaps, gro, drop) and secondary\nasync return points, release the reference inline when\nasync is set.",
"id": "GHSA-v4m9-vrgr-8xm2",
"modified": "2026-09-18T15:31:23Z",
"published": "2026-04-24T15:32:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31663"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:67471"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:68531"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:68532"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:68570"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-31663"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2461462"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f451b43c88bf2b9c038b414be580efee42e031b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1c428b03840094410c5fb6a5db30640486bbbfcb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4236c30b437b80f673b9e08c8fae38b8d471ac9e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5002beda5cac69d522dc54da0d5d463ed9c963d2"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-31663.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
MSRC_CVE-2026-31663
Vulnerability from csaf_microsoft - Published: 2026-04-26 01:04 - Updated: 2026-09-23 01:45OESA-2026-2869 (CVE-2025-10263)
Vulnerability from osv_openeuler – Published: 2026-07-06 11:11 – Updated: 2026-08-06 11:11 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work)
In smbd_destroy() we may destroy the memory so we better wait until post_send_credits_work is no longer pending and will never be started again.
I actually just hit the case using rxe:
WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe] ... [ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687149] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687185] [ T138] ? __pfx_smbd_post_recv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 5305.687356] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? _raw_spin_unlock_irqrestore+0x11/0x60 [ 5305.687389] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [cifs] [ 5305.687701] [ T138] ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ? __pfxschedule+0x10/0x10 [ 5305.687865] [ T138] ? _pfxraw_spin_lock_irq+0x10/0x10 [ 5305.687875] [ T138] ? queue_delayed_work_on+0x8e/0xa0 [ 5305.687889] [ T138] process_one_work+0x629/0xf80 [ 5305.687908] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687933] [ T138] worker_thread+0x87f/0x1570 ...
It means rxe_post_recv was called after rdma_destroy_qp(). This happened because put_receive_buffer() was triggered by ib_drain_qp() and called: queue_work(info->workqueue, &info->post_send_credits_work);(CVE-2025-39932)
In the Linux kernel, the following vulnerability has been resolved:
riscv: Sanitize syscall table indexing under speculation
The syscall number is a user-controlled value used to index into the syscall table. Use array_index_nospec() to clamp this value after the bounds check to prevent speculative out-of-bounds access and subsequent data leakage via cache side channels.(CVE-2025-71203)
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: release admin tagset if init fails
nvme_fabrics creates an NVMe/FC controller in following path:
nvmf_dev_write()
-> nvmf_create_ctrl()
-> nvme_fc_create_ctrl()
-> nvme_fc_init_ctrl()
nvme_fc_init_ctrl() allocates the admin blk-mq resources right after nvme_add_ctrl() succeeds. If any of the subsequent steps fail (changing the controller state, scheduling connect work, etc.), we jump to the fail_ctrl path, which tears down the controller references but never frees the admin queue/tag set. The leaked blk-mq allocations match the kmemleak report seen during blktests nvme/fc.
Check ctrl->ctrl.admin_tagset in the fail_ctrl path and call nvme_remove_admin_tag_set() when it is set so that all admin queue allocations are reclaimed whenever controller setup aborts.(CVE-2026-23261)
In the Linux kernel, the following vulnerability has been resolved:
arm64: io: Extract user memory type in ioremap_prot()
The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN:
| Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68
Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().(CVE-2026-23346)
In the Linux kernel, the following vulnerability has been resolved:
ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz
The only user of frag_size field in XDP RxQ info is bpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead of DMA write size. Different assumptions in ice driver configuration lead to negative tailroom.
This allows to trigger kernel panic, when using XDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to 6912 and the requested offset to a huge value, e.g. XSK_UMEM__MAX_FRAME_SIZE * 100.
Due to other quirks of the ZC configuration in ice, panic is not observed in ZC mode, but tailroom growing still fails when it should not.
Use fill queue buffer truesize instead of DMA write size in XDP RxQ info. Fix ZC mode too by using the new helper.(CVE-2026-23377)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_expect: use expect->helper
Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe.
Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.(CVE-2026-31414)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix OOB write in QUERY_INFO for compound requests
When a compound request such as READ + QUERY_INFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor.
The root cause was that smb2_get_info_sec() checked buffer space using ppntsd_size from xattr, while build_sec_desc() often synthesized a significantly larger descriptor from POSIX ACLs.
This patch introduces smb_acl_sec_desc_scratch_len() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2_calc_max_out_buf_len(), and uses exact-sized allocation + iov pinning.(CVE-2026-31432)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix leaking event log memory
During the device remove process, the device is reset, causing the configuration registers to go back to their default state, which is zero. As the driver is checking if the event log support was enabled before deallocating, it will fail if a reset happened before.
Do not check if the support was enabled, the check for 'idxd->evl' being valid (only allocated if the HW capability is available) is enough.(CVE-2026-31440)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix crash when the event log is disabled
If reporting errors to the event log is not supported by the hardware, and an error that causes Function Level Reset (FLR) is received, the driver will try to restore the event log even if it was not allocated.
Also, only try to free the event log if it was properly allocated.(CVE-2026-31443)
In the Linux kernel, the following vulnerability has been resolved:
xfs: avoid dereferencing log items after push callbacks
After xfsaild_push_item() calls iop_push(), the log item may have been freed if the AIL lock was dropped during the push. Background inode reclaim or the dquot shrinker can free the log item while the AIL lock is not held, and the tracepoints in the switch statement dereference the log item after iop_push() returns.
Fix this by capturing the log item type, flags, and LSN before calling xfsaild_push_item(), and introducing a new xfs_ail_push_class trace event class that takes these pre-captured values and the ailp pointer instead of the log item pointer.(CVE-2026-31453)
In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: fix folio isn't locked in softleaf_to_folio()
On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows:
CPU0 CPU1
deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages
In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags.
This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held.
This is a BUG_ON() before commit 93976a20345b ("mm: eliminate further swapops predicates"), which in merged in v6.19-rc1.
To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page().
[(CVE-2026-31466)
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: Avoid releasing netdev before teardown completes
The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdev_destroy() callback can proceed immediately to the call_rcu() invocation if the IFF_OVS_DATAPATH flag is already cleared on the netdev.
The ovs_netdev_detach_dev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdev_destroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like:
[ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] <TASK> [ 998.393952] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393961] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393975] ? dp_device_event+0x41/0x80 [openvswitch] [ 998.394009] ? __die_body.cold+0x8/0x12 [ 998.394016] ? die_addr+0x3c/0x60 [ 998.394027] ? exc_general_protection+0x16d/0x390 [ 998.394042] ? asm_exc_general_protection+0x26/0x30 [ 998.394058] ? dev_set_promiscuity+0x8d/0xa0 [ 998.394066] ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch] [ 998.394092] dp_device_event+0x41/0x80 [openvswitch] [ 998.394102] notifier_call_chain+0x5a/0xd0 [ 998.394106] unregister_netdevice_many_notify+0x51b/0xa60 [ 998.394110] rtnl_dellink+0x169/0x3e0 [ 998.394121] ? rt_mutex_slowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlink_rcv_msg+0x142/0x3f0 [ 998.394128] ? avc_has_perm_noaudit+0x69/0xf0 [ 998.394130] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 998.394132] netlink_rcv_skb+0x50/0x100 [ 998.394138] netlink_unicast+0x292/0x3f0 [ 998.394141] netlink_sendmsg+0x21b/0x470 [ 998.394145] _syssendmsg+0x39d/0x3d0 [ 998.394149] _sys_sendmsg+0x9a/0xe0 [ 998.394156] __sys_sendmsg+0x7a/0xd0 [ 998.394160] do_syscall_64+0x7f/0x170 [ 998.394162] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2 ---truncated---(CVE-2026-31508)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Fix static_branch_dec() underflow for aql_disable.
syzbot reported static_branch_dec() underflow in aql_enable_write(). [0]
The problem is that aql_enable_write() does not serialise concurrent write()s to the debugfs.
aql_enable_write() checks static_key_false(&aql_disable.key) and later calls static_branch_inc() or static_branch_dec(), but the state may change between the two calls.
aql_disable does not need to track inc/dec.
Let's use static_branch_enable() and static_branch_disable().
[0]: val == 0 WARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288 Modules linked in: CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full) Tainted: [U]=USER, [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311 Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00 RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4 RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a R13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98 FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0 Call Trace: <TASK> __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline] __static_key_slow_dec kernel/jump_label.c:321 [inline] static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336 aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343 short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383 vfs_write+0x2aa/0x1070 fs/read_write.c:684 ksys_pwrite64 fs/read_write.c:793 [inline] __do_sys_pwrite64 fs/read_write.c:801 [inline] __se_sys_pwrite64 fs/read_write.c:798 [inline] __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f530cf9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012 RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010 RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978 </TASK>(CVE-2026-31551)
In the Linux kernel, the following vulnerability has been resolved:
nvmet: move async event work off nvmet-wq
For target nvmet_ctrl_free() flushes ctrl->async_event_work. If nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:-
A. Async event work queued on nvmet-wq (prior to disconnect): nvmet_execute_async_event() queue_work(nvmet_wq, &ctrl->async_event_work)
nvmet_add_async_event() queue_work(nvmet_wq, &ctrl->async_event_work)
B. Full pre-work chain (RDMA CM path): nvmet_rdma_cm_handler() nvmet_rdma_queue_disconnect() __nvmet_rdma_queue_disconnect() queue_work(nvmet_wq, &queue->release_work) process_one_work() lock((wq_completion)nvmet-wq) <--------- 1st nvmet_rdma_release_queue_work()
C. Recursive path (same worker): nvmet_rdma_release_queue_work() nvmet_rdma_free_queue() nvmet_sq_destroy() nvmet_ctrl_put() nvmet_ctrl_free() flush_work(&ctrl->async_event_work) __flush_work() touch_wq_lockdep_map() lock((wq_completion)nvmet-wq) <--------- 2nd
Lockdep splat:
============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N
kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90
but task is already holding lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660
3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660 #1: ffffc9000e6cbe28 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660 #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530
Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma] Call Trace: __flush_work+0x268/0x530 nvmet_ctrl_free+0x140/0x310 [nvmet] nvmet_cq_put+0x74/0x90 [nvmet] nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma] nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma] process_one_work+0x206/0x660 worker_thread+0x184/0x320 kthread+0x10c/0x240 ret_from_fork+0x319/0x390
Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq.(CVE-2026-31557)
In the Linux kernel, the following vulnerability has been resolved:
bcache: fix cached_dev.sb_bio use-after-free and crash
In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention:
[6888366.280350] Call Trace:
[6888366.280452] blk_update_request+0x14e/0x370
[6888366.280561] blk_mq_end_request+0x1a/0x130
[6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd]
[6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd]
[6888366.280903] __complete_request+0x22/0x70 [libceph]
[6888366.281032] osd_dispatch+0x15e/0xb40 [libceph]
[6888366.281164] ? inet_recvmsg+0x5b/0xd0
[6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph]
[6888366.281405] ceph_con_process_message+0x79/0x140 [libceph]
[6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph]
[6888366.281661] ceph_con_workfn+0x329/0x680 [libceph]
After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped.
Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio.
This patch hopes to wait for sb_write to complete in cached_dev_free.
It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.(CVE-2026-31580)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: hold dev ref until after transport_finish NF_HOOK
After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown.
Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn.
For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.(CVE-2026-31663)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: clear trailing padding in build_polexpire()
build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire.
The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents.
Add the missing memset_after() call, matching build_expire().(CVE-2026-31664)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_multiport: validate range encoding in checkentry
ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end.
The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule.
Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.(CVE-2026-31681)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate owner of durable handle on reconnect
Currently, ksmbd does not verify if the user attempting to reconnect to a durable handle is the same user who originally opened the file. This allows any authenticated user to hijack an orphaned durable handle by predicting or brute-forcing the persistent ID.
According to MS-SMB2, the server MUST verify that the SecurityContext of the reconnect request matches the SecurityContext associated with the existing open. Add a durable_owner structure to ksmbd_file to store the original opener's UID, GID, and account name. and catpure the owner information when a file handle becomes orphaned. and implementing ksmbd_vfs_compare_durable_owner() to validate the identity of the requester during SMB2_CREATE (DHnC).(CVE-2026-31717)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_ecm: Fix net_device lifecycle with device_move
The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks:
console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory
Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering.
To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.(CVE-2026-31725)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if exists
hci_cmd_sync_queue_once() needs to indicate whether a queue item was added, so caller can know if callbacks are called, so it can avoid leaking resources.
Change the function to return -EEXIST if queue item already exists.
Modify all callsites to handle that.(CVE-2026-43022)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: ignore explicit helper on new expectations
Use the existing master conntrack helper, anything else is not really supported and it just makes validation more complicated, so just ignore what helper userspace suggests for this expectation.
This was uncovered when validating CTA_EXPECT_CLASS via different helper provided by userspace than the existing master conntrack helper:
BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0 Read of size 4 at addr ffff8880043fe408 by task poc/102 Call Trace: nf_ct_expect_related_report+0x2479/0x27c0 ctnetlink_create_expect+0x22b/0x3b0 ctnetlink_new_expect+0x4bd/0x5c0 nfnetlink_rcv_msg+0x67a/0x950 netlink_rcv_skb+0x120/0x350
Allowing to read kernel memory bytes off the expectation boundary.
CTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace via netlink dump.(CVE-2026-43025)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent
ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT.
The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields.
Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled.
Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation.(CVE-2026-43026)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: Wait for RCU readers during policy netns exit
xfrm_policy_fini() frees the policy_bydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first.
The policy_bydst tables are published via rcu_assign_pointer() and are looked up through rcu_dereference_check(), so netns teardown must also wait for an RCU grace period before freeing the table memory.
Fix this by adding synchronize_rcu() before freeing the policy hash tables.(CVE-2026-43091)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: ensure safe access to master conntrack
Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid.
To access exp->master safely:
-
Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away.
-
Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths.
This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section.
The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect().
However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct.
The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL.
For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master.
While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.(CVE-2026-43116)
In the Linux kernel, the following vulnerability has been resolved:
dlm: validate length in dlm_search_rsb_tree
The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree().
Add length validation to prevent potential buffer overflow.(CVE-2026-43125)
In the Linux kernel, the following vulnerability has been resolved:
ntfs3: fix circular locking dependency in run_unpack_ex
Syzbot reported a circular locking dependency between wnd->rw_lock (sbi->used.bitmap) and ni->file.run_lock.
The deadlock scenario: 1. ntfs_extend_mft() takes ni->file.run_lock then wnd->rw_lock. 2. run_unpack_ex() takes wnd->rw_lock then tries to acquire ni->file.run_lock inside ntfs_refresh_zone().
This creates an AB-BA deadlock.
Fix this by using down_read_trylock() instead of down_read() when acquiring run_lock in run_unpack_ex(). If the lock is contended, skip ntfs_refresh_zone() - the MFT zone will be refreshed on the next MFT operation. This breaks the circular dependency since we never block waiting for run_lock while holding wnd->rw_lock.(CVE-2026-43127)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: serialize sequence allocation under concurrent TLB invalidations
With concurrent TLB invalidations, completion wait randomly gets timed out because cmd_sem_val was incremented outside the IOMMU spinlock, allowing CMD_COMPL_WAIT commands to be queued out of sequence and breaking the ordering assumption in wait_on_sem(). Move the cmd_sem_val increment under iommu->lock so completion sequence allocation is serialized with command queuing. And remove the unnecessary return.(CVE-2026-43220)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: prevent races in ->query_interfaces()
It was possible for two query interface works to be concurrently trying to update the interfaces.
Prevent this by checking and updating iface_last_update under iface_lock.(CVE-2026-43239)
In the Linux kernel, the following vulnerability has been resolved:
md raid: fix hang when stopping arrays with metadata through dm-raid
When using device-mapper's dm-raid target, stopping a RAID array can cause the system to hang under specific conditions.
This occurs when:
-
A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices)
-
The top-level RAID device is then removed
Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls md_stop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-intent operations and causing an indefinite block.
Fix:
-
Prevent bitmap flushing when md_stop() is called from dm-raid destructor context and avoid a quiescing/unquescing cycle which could also cause I/O
-
Still allow write-intent bitmap flushing when called from dm-raid suspend context
This ensures that RAID array teardown can complete successfully even when the underlying devices are in a suspended state.
This second patch uses md_is_rdwr() to distinguish between suspend and destructor paths as elaborated on above.(CVE-2026-43309)
In the Linux kernel, the following vulnerability has been resolved:
spi: spidev: fix lock inversion between spi_lock and buf_lock
The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path:
write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock
This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks:
WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK ***
The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor.
Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock.
buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues.
This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour.(CVE-2026-43319)
In the Linux kernel, the following vulnerability has been resolved:
sched/fair: Fix zero_vruntime tracking fix
John reported that stress-ng-yield could make his machine unhappy and managed to bisect it to commit b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking").
The combination of yield and that commit was specific enough to hypothesize the following scenario:
Suppose we have 2 runnable tasks, both doing yield. Then one will be eligible and one will not be, because the average position must be in between these two entities.
Therefore, the runnable task will be eligible, and be promoted a full slice (all the tasks do is yield after all). This causes it to jump over the other task and now the other task is eligible and current is no longer. So we schedule.
Since we are runnable, there is no {de,en}queue. All we have is the __{en,de}queue_entity() from {put_prev,set_next}_task(). But per the fingered commit, those two no longer move zero_vruntime.
All that moves zero_vruntime are tick and full {de,en}queue.
This means, that if the two tasks playing leapfrog can reach the critical speed to reach the overflow point inside one tick's worth of time, we're up a creek.
Additionally, when multiple cgroups are involved, there is no guarantee the tick will in fact hit every cgroup in a timely manner. Statistically speaking it will, but that same statistics does not rule out the possibility of one cgroup not getting a tick for a significant amount of time -- however unlikely.
Therefore, just like with the yield() case, force an update at the end of every slice. This ensures the update is never more than a single slice behind and the whole thing is within 2 lag bounds as per the comment on entity_key().(CVE-2026-43323)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: require a full NFS mode SID before reading mode bits
parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits.
That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE.
Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl.(CVE-2026-43350)
In the Linux kernel, the following vulnerability has been resolved:
e1000/e1000e: Fix leak in DMA error cleanup
If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb.
Because count is incremented after a successful mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping would leak.
In these commits, a faulty while condition caused an infinite loop in dma_error: Commit 03b1320dfcee ("e1000e: remove use of skb_dma_map from e1000e driver") Commit 602c0554d7b0 ("e1000: remove use of skb_dma_map from e1000 driver")
Commit c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()") fixed the infinite loop, but introduced the off-by-one error.
This issue may still exist in the igbvf driver, but I did not address it in this patch.(CVE-2026-43445)
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: Fix race bug in nvme_poll_irqdisable()
In the following scenario, pdev can be disabled between (1) and (3) by (2). This sets pdev->msix_enabled = 0. Then, pci_irq_vector() will return MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2). This causes IRQ warning because it tries to enable INTx IRQ that has never been disabled before.
To fix this, save IRQ number into a local variable and ensure disable_irq() and enable_irq() operate on the same IRQ number. Even if pci_free_irq_vectors() frees the IRQ concurrently, disable_irq() and enable_irq() on a stale IRQ number is still valid and safe, and the depth accounting reamins balanced.
task 1: nvme_poll_irqdisable() disable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(1) enable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(3)
task 2: nvme_reset_work() nvme_dev_disable() pdev->msix_enable = 0; ...(2)
crash log:
------------[ cut here ]------------ Unbalanced enable for IRQ 10 WARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26 Modules linked in: CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_timeout_work RIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753 Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9 RSP: 0018:ffffc900001bf550 EFLAGS: 00010046 RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90 RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0 RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000 R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293 FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0 Call Trace: <TASK> enable_irq+0x121/0x1e0 kernel/irq/manage.c:797 nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blk_mq_rq_timed_out block/blk-mq.c:1653 [inline] blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721 bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292 __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline] sbitmap_for_each_set include/linux/sbitmap.h:290 [inline] bt_for_each block/blk-mq-tag.c:324 [inline] blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536 blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 </TASK> irq event stamp: 74478 hardirqs last enabled at (74477): [<ffffffffb5720a9c>] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline] hardirqs last enabled at (74477): [<ffffffffb5720a9c>] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202 hardirqs last disabled at (74478): [<ffffffffb57207b5>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (74478): [<ffffffffb57207b5>] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162 softirqs last enabled at (74304): [<ffffffffb1e9466c>] __do_softirq kernel/softirq.c:656 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] invoke_softirq kernel/softirq.c:496 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] __irq_exit_rcu+0xdc/0x120 ---truncated---(CVE-2026-43448)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation
Ulrich reports a regression with nfqueue:
If an application did not set the 'F_GSO' capability flag and a gso packet with an unconfirmed nf_conn entry is received all packets are now dropped instead of queued, because the check happens after skb_gso_segment(). In that case, we did have exclusive ownership of the skb and its associated conntrack entry. The elevated use count is due to skb_clone happening via skb_gso_segment().
Move the check so that its peformed vs. the aggregated packet.
Then, annotate the individual segments except the first one so we can do a 2nd check at reinject time.
For the normal case, where userspace does in-order reinjects, this avoids packet drops: first reinjected segment continues traversal and confirms entry, remaining segments observe the confirmed entry.
While at it, simplify nf_ct_drop_unconfirmed(): We only care about unconfirmed entries with a refcnt > 1, there is no need to special-case dying entries.
This only happens with UDP. With TCP, the only unconfirmed packet will be the TCP SYN, those aren't aggregated by GRO.
Next patch adds a udpgro test case to cover this scenario.(CVE-2026-45859)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Add missing save/restore handling of LBR MSRs
MSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by KVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So save/restore is completely broken.
Fix it by adding the MSRs to msrs_to_save_base, and allowing writes to LBR MSRs from userspace only (as they are read-only MSRs) if LBR virtualization is enabled. Additionally, to correctly restore L1's LBRs while L2 is running, make sure the LBRs are copied from the captured VMCB01 save area in svm_copy_vmrun_state().
Note, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn't reported as an MSR to save/restore.
Note #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already handles unsupported reads and writes thanks to commit b5e2fec0ebc3 ("KVM: Ignore DEBUGCTL MSRs with no effect") (kvm_do_msr_access() will morph the unsupported userspace write into a nop).
sean: guard with lbrv checks, massage changelog
In the Linux kernel, the following vulnerability has been resolved:
x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache
Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.(CVE-2026-46174)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_inner: Fix IPv6 inner_thoff desync
In nft_inner_parse_l2l3(), when processing inner IPv6 packets, ipv6_find_hdr() correctly computes the transport header offset traversing all extension headers, but the result is immediately overwritten with nhoff + sizeof(_ip6h) (40 bytes), which only accounts for the IPv6 base header. This creates a desync between inner_thoff (wrong — points to extension header start) and l4proto (correct — e.g., IPPROTO_TCP), enabling transport header forgery and potential firewall bypass. This issue affects stable versions from Linux 6.2.
For comparison, the normal (non-inner) IPv6 path correctly preserves ipv6_find_hdr()'s result. Removing the incorrect overwrite ensures that ipv6_find_hdr()'s calculated transport header offset is preserved, thereby fixing the desynchronization.(CVE-2026-46244)
In the Linux kernel, the following vulnerability has been resolved:
tap: free page on error paths in tap_get_user_xdp()
tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk.
Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().(CVE-2026-46320)
In the Linux kernel, the following vulnerability has been resolved:
tun: free page on short-frame rejection in tun_xdp_one()
tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk.
A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.(CVE-2026-46321)
In the Linux kernel, the following vulnerability has been resolved:
tun: free page on build_skb failure in tun_xdp_one()
When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk.
Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.(CVE-2026-46322)
In the Linux kernel, the following vulnerability has been resolved:
net: gro: don't merge zcopy skbs
skb_gro_receive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFL_MANAGED_FRAG_REFS flag.
When SKBFL_MANAGED_FRAG_REFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF.
When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs.(CVE-2026-46323)
In the Linux kernel, the following vulnerability has been resolved:
Revert "net/smc: Introduce TCP ULP support"
This reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.
As reported by Al Viro, the TCP ULP support for SMC is fundamentally
broken. The implementation attempts to convert an active TCP socket
into an SMC socket by modifying the underlying struct file, dentry,
and inode in-place, which violates core VFS invariants that assume
these structures are immutable for an open file, creating a risk of
use after free errors and general system instability.
Given the severity of this design flaw and the fact that cleaner alternatives (e.g., LD_PRELOAD, BPF) exist for legacy application transparency, the correct course of action is to remove this feature entirely.(CVE-2026-46330)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"kernel-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"kernel-debugsource-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"kernel-devel-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"kernel-extra-modules-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"kernel-headers-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"kernel-source-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"kernel-tools-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"perf-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"perf-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"python3-perf-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.3.17.150.oe2403sp3.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"kernel-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"kernel-debugsource-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"kernel-devel-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"kernel-extra-modules-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"kernel-headers-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"kernel-source-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"kernel-tools-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"perf-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"perf-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"python3-perf-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-145.3.17.150.oe2403sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nArm C1-Ultra, C1-Premium, Neoverse V3 \u0026amp; V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 \u0026amp; X1C, Cortex-A710, Cortex-A78, A78AE \u0026amp; A78C, Cortex-A77, Cortex-A76 \u0026amp; A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: let smbd_destroy() call disable_work_sync(\u0026amp;info-\u0026gt;post_send_credits_work)\n\nIn smbd_destroy() we may destroy the memory so we better\nwait until post_send_credits_work is no longer pending\nand will never be started again.\n\nI actually just hit the case using rxe:\n\nWARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe]\n...\n[ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs]\n[ 5305.687135] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687149] [ T138] ? __kasan_check_write+0x14/0x30\n[ 5305.687185] [ T138] ? __pfx_smbd_post_recv+0x10/0x10 [cifs]\n[ 5305.687329] [ T138] ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 5305.687356] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687368] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687378] [ T138] ? _raw_spin_unlock_irqrestore+0x11/0x60\n[ 5305.687389] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs]\n[ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [cifs]\n[ 5305.687701] [ T138] ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs]\n[ 5305.687855] [ T138] ? __pfx___schedule+0x10/0x10\n[ 5305.687865] [ T138] ? __pfx__raw_spin_lock_irq+0x10/0x10\n[ 5305.687875] [ T138] ? queue_delayed_work_on+0x8e/0xa0\n[ 5305.687889] [ T138] process_one_work+0x629/0xf80\n[ 5305.687908] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687917] [ T138] ? __kasan_check_write+0x14/0x30\n[ 5305.687933] [ T138] worker_thread+0x87f/0x1570\n...\n\nIt means rxe_post_recv was called after rdma_destroy_qp().\nThis happened because put_receive_buffer() was triggered\nby ib_drain_qp() and called:\nqueue_work(info-\u0026gt;workqueue, \u0026amp;info-\u0026gt;post_send_credits_work);(CVE-2025-39932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Sanitize syscall table indexing under speculation\n\nThe syscall number is a user-controlled value used to index into the\nsyscall table. Use array_index_nospec() to clamp this value after the\nbounds check to prevent speculative out-of-bounds access and subsequent\ndata leakage via cache side channels.(CVE-2025-71203)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-fc: release admin tagset if init fails\n\nnvme_fabrics creates an NVMe/FC controller in following path:\n\n nvmf_dev_write()\n -\u0026gt; nvmf_create_ctrl()\n -\u0026gt; nvme_fc_create_ctrl()\n -\u0026gt; nvme_fc_init_ctrl()\n\nnvme_fc_init_ctrl() allocates the admin blk-mq resources right after\nnvme_add_ctrl() succeeds. If any of the subsequent steps fail (changing\nthe controller state, scheduling connect work, etc.), we jump to the\nfail_ctrl path, which tears down the controller references but never\nfrees the admin queue/tag set. The leaked blk-mq allocations match the\nkmemleak report seen during blktests nvme/fc.\n\nCheck ctrl-\u0026gt;ctrl.admin_tagset in the fail_ctrl path and call\nnvme_remove_admin_tag_set() when it is set so that all admin queue\nallocations are reclaimed whenever controller setup aborts.(CVE-2026-23261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: io: Extract user memory type in ioremap_prot()\n\nThe only caller of ioremap_prot() outside of the generic ioremap()\nimplementation is generic_access_phys(), which passes a \u0026apos;pgprot_t\u0026apos; value\ndetermined from the user mapping of the target \u0026apos;pfn\u0026apos; being accessed by\nthe kernel. On arm64, the \u0026apos;pgprot_t\u0026apos; contains all of the non-address\nbits from the pte, including the permission controls, and so we end up\nreturning a new user mapping from ioremap_prot() which faults when\naccessed from the kernel on systems with PAN:\n\n | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000\n | ...\n | Call trace:\n | __memcpy_fromio+0x80/0xf8\n | generic_access_phys+0x20c/0x2b8\n | __access_remote_vm+0x46c/0x5b8\n | access_remote_vm+0x18/0x30\n | environ_read+0x238/0x3e8\n | vfs_read+0xe4/0x2b0\n | ksys_read+0xcc/0x178\n | __arm64_sys_read+0x4c/0x68\n\nExtract only the memory type from the user \u0026apos;pgprot_t\u0026apos; in ioremap_prot()\nand assert that we\u0026apos;re being passed a user mapping, to protect us against\nany changes in future that may require additional handling. To avoid\nfalsely flagging users of ioremap(), provide our own ioremap() macro\nwhich simply wraps __ioremap_prot().(CVE-2026-23346)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz\n\nThe only user of frag_size field in XDP RxQ info is\nbpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead\nof DMA write size. Different assumptions in ice driver configuration lead\nto negative tailroom.\n\nThis allows to trigger kernel panic, when using\nXDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to\n6912 and the requested offset to a huge value, e.g.\nXSK_UMEM__MAX_FRAME_SIZE * 100.\n\nDue to other quirks of the ZC configuration in ice, panic is not observed\nin ZC mode, but tailroom growing still fails when it should not.\n\nUse fill queue buffer truesize instead of DMA write size in XDP RxQ info.\nFix ZC mode too by using the new helper.(CVE-2026-23377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_expect: use expect-\u0026gt;helper\n\nUse expect-\u0026gt;helper in ctnetlink and /proc to dump the helper name.\nUsing nfct_help() without holding a reference to the master conntrack\nis unsafe.\n\nUse exp-\u0026gt;master-\u0026gt;helper in ctnetlink path if userspace does not provide\nan explicit helper when creating an expectation to retain the existing\nbehaviour. The ctnetlink expectation path holds the reference on the\nmaster conntrack and nf_conntrack_expect lock and the nfnetlink glue\npath refers to the master ct that is attached to the skb.(CVE-2026-31414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix OOB write in QUERY_INFO for compound requests\n\nWhen a compound request such as READ + QUERY_INFO(Security) is received,\nand the first command (READ) consumes most of the response buffer,\nksmbd could write beyond the allocated buffer while building a security\ndescriptor.\n\nThe root cause was that smb2_get_info_sec() checked buffer space using\nppntsd_size from xattr, while build_sec_desc() often synthesized a\nsignificantly larger descriptor from POSIX ACLs.\n\nThis patch introduces smb_acl_sec_desc_scratch_len() to accurately\ncompute the final descriptor size beforehand, performs proper buffer\nchecking with smb2_calc_max_out_buf_len(), and uses exact-sized\nallocation + iov pinning.(CVE-2026-31432)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix leaking event log memory\n\nDuring the device remove process, the device is reset, causing the\nconfiguration registers to go back to their default state, which is\nzero. As the driver is checking if the event log support was enabled\nbefore deallocating, it will fail if a reset happened before.\n\nDo not check if the support was enabled, the check for \u0026apos;idxd-\u0026gt;evl\u0026apos;\nbeing valid (only allocated if the HW capability is available) is\nenough.(CVE-2026-31440)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix crash when the event log is disabled\n\nIf reporting errors to the event log is not supported by the hardware,\nand an error that causes Function Level Reset (FLR) is received, the\ndriver will try to restore the event log even if it was not allocated.\n\nAlso, only try to free the event log if it was properly allocated.(CVE-2026-31443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: avoid dereferencing log items after push callbacks\n\nAfter xfsaild_push_item() calls iop_push(), the log item may have been\nfreed if the AIL lock was dropped during the push. Background inode\nreclaim or the dquot shrinker can free the log item while the AIL lock\nis not held, and the tracepoints in the switch statement dereference\nthe log item after iop_push() returns.\n\nFix this by capturing the log item type, flags, and LSN before calling\nxfsaild_push_item(), and introducing a new xfs_ail_push_class trace\nevent class that takes these pre-captured values and the ailp pointer\ninstead of the log item pointer.(CVE-2026-31453)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: fix folio isn\u0026apos;t locked in softleaf_to_folio()\n\nOn arm64 server, we found folio that get from migration entry isn\u0026apos;t locked\nin softleaf_to_folio(). This issue triggers when mTHP splitting and\nzap_nonpresent_ptes() races, and the root cause is lack of memory barrier\nin softleaf_to_folio(). The race is as follows:\n\n\tCPU0 CPU1\n\ndeferred_split_scan() zap_nonpresent_ptes()\n lock folio\n split_folio()\n unmap_folio()\n change ptes to migration entries\n __split_folio_to_order() softleaf_to_folio()\n set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry))\n smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio))\n prep_compound_page() for tail pages\n\nIn __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages\nare visible before the tail page becomes non-compound. smp_wmb() should\nbe paired with smp_rmb() in softleaf_to_folio(), which is missed. As a\nresult, if zap_nonpresent_ptes() accesses migration entry that stores tail\npfn, softleaf_to_folio() may see the updated compound_head of tail page\nbefore page-\u0026gt;flags.\n\nThis issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio()\nbecause of the race between folio split and zap_nonpresent_ptes()\nleading to a folio incorrectly undergoing modification without a folio\nlock being held.\n\nThis is a BUG_ON() before commit 93976a20345b (\u0026quot;mm: eliminate further\nswapops predicates\u0026quot;), which in merged in v6.19-rc1.\n\nTo fix it, add missing smp_rmb() if the softleaf entry is migration entry\nin softleaf_to_folio() and softleaf_to_page().\n\n[(CVE-2026-31466)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: Avoid releasing netdev before teardown completes\n\nThe patch cited in the Fixes tag below changed the teardown code for\nOVS ports to no longer unconditionally take the RTNL. After this change,\nthe netdev_destroy() callback can proceed immediately to the call_rcu()\ninvocation if the IFF_OVS_DATAPATH flag is already cleared on the\nnetdev.\n\nThe ovs_netdev_detach_dev() function clears the flag before completing\nthe unregistration, and if it gets preempted after clearing the flag (as\ncan happen on an -rt kernel), netdev_destroy() can complete and the\ndevice can be freed before the unregistration completes. This leads to a\nsplat like:\n\n[ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI\n[ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT\n[ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025\n[ 998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0\n[ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 \u0026lt;48\u0026gt; 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90\n[ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246\n[ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000\n[ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05\n[ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000\n[ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006\n[ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000\n[ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000\n[ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0\n[ 998.393944] PKRU: 55555554\n[ 998.393946] Call Trace:\n[ 998.393949] \u0026lt;TASK\u0026gt;\n[ 998.393952] ? show_trace_log_lvl+0x1b0/0x2f0\n[ 998.393961] ? show_trace_log_lvl+0x1b0/0x2f0\n[ 998.393975] ? dp_device_event+0x41/0x80 [openvswitch]\n[ 998.394009] ? __die_body.cold+0x8/0x12\n[ 998.394016] ? die_addr+0x3c/0x60\n[ 998.394027] ? exc_general_protection+0x16d/0x390\n[ 998.394042] ? asm_exc_general_protection+0x26/0x30\n[ 998.394058] ? dev_set_promiscuity+0x8d/0xa0\n[ 998.394066] ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch]\n[ 998.394092] dp_device_event+0x41/0x80 [openvswitch]\n[ 998.394102] notifier_call_chain+0x5a/0xd0\n[ 998.394106] unregister_netdevice_many_notify+0x51b/0xa60\n[ 998.394110] rtnl_dellink+0x169/0x3e0\n[ 998.394121] ? rt_mutex_slowlock.constprop.0+0x95/0xd0\n[ 998.394125] rtnetlink_rcv_msg+0x142/0x3f0\n[ 998.394128] ? avc_has_perm_noaudit+0x69/0xf0\n[ 998.394130] ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n[ 998.394132] netlink_rcv_skb+0x50/0x100\n[ 998.394138] netlink_unicast+0x292/0x3f0\n[ 998.394141] netlink_sendmsg+0x21b/0x470\n[ 998.394145] ____sys_sendmsg+0x39d/0x3d0\n[ 998.394149] ___sys_sendmsg+0x9a/0xe0\n[ 998.394156] __sys_sendmsg+0x7a/0xd0\n[ 998.394160] do_syscall_64+0x7f/0x170\n[ 998.394162] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 998.394165] RIP: 0033:0x7fad61bf4724\n[ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89\n[ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n[ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724\n[ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003\n[ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f\n[ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2\n---truncated---(CVE-2026-31508)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Fix static_branch_dec() underflow for aql_disable.\n\nsyzbot reported static_branch_dec() underflow in aql_enable_write(). [0]\n\nThe problem is that aql_enable_write() does not serialise concurrent\nwrite()s to the debugfs.\n\naql_enable_write() checks static_key_false(\u0026amp;aql_disable.key) and\nlater calls static_branch_inc() or static_branch_dec(), but the\nstate may change between the two calls.\n\naql_disable does not need to track inc/dec.\n\nLet\u0026apos;s use static_branch_enable() and static_branch_disable().\n\n[0]:\nval == 0\nWARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288\nModules linked in:\nCPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full)\nTainted: [U]=USER, [L]=SOFTLOCKUP\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026\nRIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311\nCode: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 \u0026lt;0f\u0026gt; 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00\nRSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4\nRDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000\nRBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a\nR13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98\nFS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline]\n __static_key_slow_dec kernel/jump_label.c:321 [inline]\n static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336\n aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343\n short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383\n vfs_write+0x2aa/0x1070 fs/read_write.c:684\n ksys_pwrite64 fs/read_write.c:793 [inline]\n __do_sys_pwrite64 fs/read_write.c:801 [inline]\n __se_sys_pwrite64 fs/read_write.c:798 [inline]\n __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f530cf9aeb9\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012\nRAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9\nRDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010\nRBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000\nR10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978\n \u0026lt;/TASK\u0026gt;(CVE-2026-31551)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: move async event work off nvmet-wq\n\nFor target nvmet_ctrl_free() flushes ctrl-\u0026gt;async_event_work.\nIf nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueue\ncompletion for the same worker:-\n\nA. Async event work queued on nvmet-wq (prior to disconnect):\n nvmet_execute_async_event()\n queue_work(nvmet_wq, \u0026amp;ctrl-\u0026gt;async_event_work)\n\n nvmet_add_async_event()\n queue_work(nvmet_wq, \u0026amp;ctrl-\u0026gt;async_event_work)\n\nB. Full pre-work chain (RDMA CM path):\n nvmet_rdma_cm_handler()\n nvmet_rdma_queue_disconnect()\n __nvmet_rdma_queue_disconnect()\n queue_work(nvmet_wq, \u0026amp;queue-\u0026gt;release_work)\n process_one_work()\n lock((wq_completion)nvmet-wq) \u0026lt;--------- 1st\n nvmet_rdma_release_queue_work()\n\nC. Recursive path (same worker):\n nvmet_rdma_release_queue_work()\n nvmet_rdma_free_queue()\n nvmet_sq_destroy()\n nvmet_ctrl_put()\n nvmet_ctrl_free()\n flush_work(\u0026amp;ctrl-\u0026gt;async_event_work)\n __flush_work()\n touch_wq_lockdep_map()\n lock((wq_completion)nvmet-wq) \u0026lt;--------- 2nd\n\nLockdep splat:\n\n ============================================\n WARNING: possible recursive locking detected\n 6.19.0-rc3nvme+ #14 Tainted: G N\n --------------------------------------------\n kworker/u192:42/44933 is trying to acquire lock:\n ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90\n\n but task is already holding lock:\n ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660\n\n 3 locks held by kworker/u192:42/44933:\n #0: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660\n #1: ffffc9000e6cbe28 ((work_completion)(\u0026amp;queue-\u0026gt;release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660\n #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530\n\n Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma]\n Call Trace:\n __flush_work+0x268/0x530\n nvmet_ctrl_free+0x140/0x310 [nvmet]\n nvmet_cq_put+0x74/0x90 [nvmet]\n nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma]\n nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma]\n process_one_work+0x206/0x660\n worker_thread+0x184/0x320\n kthread+0x10c/0x240\n ret_from_fork+0x319/0x390\n\nMove async event work to a dedicated nvmet-aen-wq to avoid reentrant\nflush on nvmet-wq.(CVE-2026-31557)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: fix cached_dev.sb_bio use-after-free and crash\n\nIn our production environment, we have received multiple crash reports\nregarding libceph, which have caught our attention:\n\n```\n[6888366.280350] Call Trace:\n[6888366.280452] blk_update_request+0x14e/0x370\n[6888366.280561] blk_mq_end_request+0x1a/0x130\n[6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd]\n[6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd]\n[6888366.280903] __complete_request+0x22/0x70 [libceph]\n[6888366.281032] osd_dispatch+0x15e/0xb40 [libceph]\n[6888366.281164] ? inet_recvmsg+0x5b/0xd0\n[6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph]\n[6888366.281405] ceph_con_process_message+0x79/0x140 [libceph]\n[6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph]\n[6888366.281661] ceph_con_workfn+0x329/0x680 [libceph]\n```\n\nAfter analyzing the coredump file, we found that the address of\ndc-\u0026gt;sb_bio has been freed. We know that cached_dev is only freed when it\nis stopped.\n\nSince sb_bio is a part of struct cached_dev, rather than an alloc every\ntime. If the device is stopped while writing to the superblock, the\nreleased address will be accessed at endio.\n\nThis patch hopes to wait for sb_write to complete in cached_dev_free.\n\nIt should be noted that we analyzed the cause of the problem, then tell\nall details to the QWEN and adopted the modifications it made.(CVE-2026-31580)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: hold dev ref until after transport_finish NF_HOOK\n\nAfter async crypto completes, xfrm_input_resume() calls dev_put()\nimmediately on re-entry before the skb reaches transport_finish.\nThe skb-\u0026gt;dev pointer is then used inside NF_HOOK and its okfn,\nwhich can race with device teardown.\n\nRemove the dev_put from the async resumption entry and instead\ndrop the reference after the NF_HOOK call in transport_finish,\nusing a saved device pointer since NF_HOOK may consume the skb.\nThis covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip\nthe okfn.\n\nFor non-transport exits (decaps, gro, drop) and secondary\nasync return points, release the reference inline when\nasync is set.(CVE-2026-31663)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: clear trailing padding in build_polexpire()\n\nbuild_expire() clears the trailing padding bytes of struct\nxfrm_user_expire after setting the hard field via memset_after(),\nbut the analogous function build_polexpire() does not do this for\nstruct xfrm_user_polexpire.\n\nThe padding bytes after the __u8 hard field are left\nuninitialized from the heap allocation, and are then sent to\nuserspace via netlink multicast to XFRMNLGRP_EXPIRE listeners,\nleaking kernel heap memory contents.\n\nAdd the missing memset_after() call, matching build_expire().(CVE-2026-31664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_multiport: validate range encoding in checkentry\n\nports_match_v1() treats any non-zero pflags entry as the start of a\nport range and unconditionally consumes the next ports[] element as\nthe range end.\n\nThe checkentry path currently validates protocol, flags and count, but\nit does not validate the range encoding itself. As a result, malformed\nrules can mark the last slot as a range start or place two range starts\nback to back, leaving ports_match_v1() to step past the last valid\nports[] element while interpreting the rule.\n\nReject malformed multiport v1 rules in checkentry by validating that\neach range start has a following element and that the following element\nis not itself marked as another range start.(CVE-2026-31681)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: validate owner of durable handle on reconnect\n\nCurrently, ksmbd does not verify if the user attempting to reconnect\nto a durable handle is the same user who originally opened the file.\nThis allows any authenticated user to hijack an orphaned durable handle\nby predicting or brute-forcing the persistent ID.\n\nAccording to MS-SMB2, the server MUST verify that the SecurityContext\nof the reconnect request matches the SecurityContext associated with\nthe existing open.\nAdd a durable_owner structure to ksmbd_file to store the original opener\u0026apos;s\nUID, GID, and account name. and catpure the owner information when a file\nhandle becomes orphaned. and implementing ksmbd_vfs_compare_durable_owner()\nto validate the identity of the requester during SMB2_CREATE (DHnC).(CVE-2026-31717)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_ecm: Fix net_device lifecycle with device_move\n\nThe net_device is allocated during function instance creation and\nregistered during the bind phase with the gadget device as its sysfs\nparent. When the function unbinds, the parent device is destroyed, but\nthe net_device survives, resulting in dangling sysfs symlinks:\n\n console:/ # ls -l /sys/class/net/usb0\n lrwxrwxrwx ... /sys/class/net/usb0 -\u0026gt;\n /sys/devices/platform/.../gadget.0/net/usb0\n console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0\n ls: .../gadget.0/net/usb0: No such file or directory\n\nUse device_move() to reparent the net_device between the gadget device\ntree and /sys/devices/virtual across bind and unbind cycles. During the\nfinal unbind, calling device_move(NULL) moves the net_device to the\nvirtual device tree before the gadget device is destroyed. On rebinding,\ndevice_move() reparents the device back under the new gadget, ensuring\nproper sysfs topology and power management ordering.\n\nTo maintain compatibility with legacy composite drivers (e.g., multi.c),\nthe bound flag is used to indicate whether the network device is shared\nand pre-registered during the legacy driver\u0026apos;s bind phase.(CVE-2026-31725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if exists\n\nhci_cmd_sync_queue_once() needs to indicate whether a queue item was\nadded, so caller can know if callbacks are called, so it can avoid\nleaking resources.\n\nChange the function to return -EEXIST if queue item already exists.\n\nModify all callsites to handle that.(CVE-2026-43022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: ignore explicit helper on new expectations\n\nUse the existing master conntrack helper, anything else is not really\nsupported and it just makes validation more complicated, so just ignore\nwhat helper userspace suggests for this expectation.\n\nThis was uncovered when validating CTA_EXPECT_CLASS via different helper\nprovided by userspace than the existing master conntrack helper:\n\n BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0\n Read of size 4 at addr ffff8880043fe408 by task poc/102\n Call Trace:\n nf_ct_expect_related_report+0x2479/0x27c0\n ctnetlink_create_expect+0x22b/0x3b0\n ctnetlink_new_expect+0x4bd/0x5c0\n nfnetlink_rcv_msg+0x67a/0x950\n netlink_rcv_skb+0x120/0x350\n\nAllowing to read kernel memory bytes off the expectation boundary.\n\nCTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace\nvia netlink dump.(CVE-2026-43025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent\n\nctnetlink_alloc_expect() allocates expectations from a non-zeroing\nslab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not\npresent in the netlink message, saved_addr and saved_proto are\nnever initialized. Stale data from a previous slab occupant can\nthen be dumped to userspace by ctnetlink_exp_dump_expect(), which\nchecks these fields to decide whether to emit CTA_EXPECT_NAT.\n\nThe safe sibling nf_ct_expect_init(), used by the packet path,\nexplicitly zeroes these fields.\n\nZero saved_addr, saved_proto and dir in the else branch, guarded\nby IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when\nNAT is enabled.\n\nConfirmed by priming the expect slab with NAT-bearing expectations,\nfreeing them, creating a new expectation without CTA_EXPECT_NAT,\nand observing that the ctnetlink dump emits a spurious\nCTA_EXPECT_NAT containing stale data from the prior allocation.(CVE-2026-43026)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Wait for RCU readers during policy netns exit\n\nxfrm_policy_fini() frees the policy_bydst hash tables after flushing the\npolicy work items and deleting all policies, but it does not wait for\nconcurrent RCU readers to leave their read-side critical sections first.\n\nThe policy_bydst tables are published via rcu_assign_pointer() and are\nlooked up through rcu_dereference_check(), so netns teardown must also\nwait for an RCU grace period before freeing the table memory.\n\nFix this by adding synchronize_rcu() before freeing the policy hash tables.(CVE-2026-43091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: ensure safe access to master conntrack\n\nHolding reference on the expectation is not sufficient, the master\nconntrack object can just go away, making exp-\u0026gt;master invalid.\n\nTo access exp-\u0026gt;master safely:\n\n- Grab the nf_conntrack_expect_lock, this gets serialized with\n clean_from_lists() which also holds this lock when the master\n conntrack goes away.\n\n- Hold reference on master conntrack via nf_conntrack_find_get().\n Not so easy since the master tuple to look up for the master conntrack\n is not available in the existing problematic paths.\n\nThis patch goes for extending the nf_conntrack_expect_lock section\nto address this issue for simplicity, in the cases that are described\nbelow this is just slightly extending the lock section.\n\nThe add expectation command already holds a reference to the master\nconntrack from ctnetlink_create_expect().\n\nHowever, the delete expectation command needs to grab the spinlock\nbefore looking up for the expectation. Expand the existing spinlock\nsection to address this to cover the expectation lookup. Note that,\nthe nf_ct_expect_iterate_net() calls already grabs the spinlock while\niterating over the expectation table, which is correct.\n\nThe get expectation command needs to grab the spinlock to ensure master\nconntrack does not go away. This also expands the existing spinlock\nsection to cover the expectation lookup too. I needed to move the\nnetlink skb allocation out of the spinlock to keep it GFP_KERNEL.\n\nFor the expectation events, the IPEXP_DESTROY event is already delivered\nunder the spinlock, just move the delivery of IPEXP_NEW under the\nspinlock too because the master conntrack event cache is reached through\nexp-\u0026gt;master.\n\nWhile at it, add lockdep notations to help identify what codepaths need\nto grab the spinlock.(CVE-2026-43116)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndlm: validate length in dlm_search_rsb_tree\n\nThe len parameter in dlm_dump_rsb_name() is not validated and comes\nfrom network messages. When it exceeds DLM_RESNAME_MAXLEN, it can\ncause out-of-bounds write in dlm_search_rsb_tree().\n\nAdd length validation to prevent potential buffer overflow.(CVE-2026-43125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs3: fix circular locking dependency in run_unpack_ex\n\nSyzbot reported a circular locking dependency between wnd-\u0026gt;rw_lock\n(sbi-\u0026gt;used.bitmap) and ni-\u0026gt;file.run_lock.\n\nThe deadlock scenario:\n1. ntfs_extend_mft() takes ni-\u0026gt;file.run_lock then wnd-\u0026gt;rw_lock.\n2. run_unpack_ex() takes wnd-\u0026gt;rw_lock then tries to acquire\n ni-\u0026gt;file.run_lock inside ntfs_refresh_zone().\n\nThis creates an AB-BA deadlock.\n\nFix this by using down_read_trylock() instead of down_read() when\nacquiring run_lock in run_unpack_ex(). If the lock is contended,\nskip ntfs_refresh_zone() - the MFT zone will be refreshed on the\nnext MFT operation. This breaks the circular dependency since we\nnever block waiting for run_lock while holding wnd-\u0026gt;rw_lock.(CVE-2026-43127)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: serialize sequence allocation under concurrent TLB invalidations\n\nWith concurrent TLB invalidations, completion wait randomly gets timed out\nbecause cmd_sem_val was incremented outside the IOMMU spinlock, allowing\nCMD_COMPL_WAIT commands to be queued out of sequence and breaking the\nordering assumption in wait_on_sem().\nMove the cmd_sem_val increment under iommu-\u0026gt;lock so completion sequence\nallocation is serialized with command queuing.\nAnd remove the unnecessary return.(CVE-2026-43220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: prevent races in -\u0026gt;query_interfaces()\n\nIt was possible for two query interface works to be concurrently trying\nto update the interfaces.\n\nPrevent this by checking and updating iface_last_update under\niface_lock.(CVE-2026-43239)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd raid: fix hang when stopping arrays with metadata through dm-raid\n\nWhen using device-mapper\u0026apos;s dm-raid target, stopping a RAID array can cause\nthe system to hang under specific conditions.\n\nThis occurs when:\n\n- A dm-raid managed device tree is suspended from top to bottom\n (the top-level RAID device is suspended first, followed by its\n underlying metadata and data devices)\n\n- The top-level RAID device is then removed\n\nRemoving the top-level device triggers a hang in the following sequence:\nthe dm-raid destructor calls md_stop(), which tries to flush the\nwrite-intent bitmap by writing to the metadata sub-devices. However, these\ndevices are already suspended, making them unable to complete the write-intent\noperations and causing an indefinite block.\n\nFix:\n\n- Prevent bitmap flushing when md_stop() is called from dm-raid\ndestructor context\n and avoid a quiescing/unquescing cycle which could also cause I/O\n\n- Still allow write-intent bitmap flushing when called from dm-raid\nsuspend context\n\nThis ensures that RAID array teardown can complete successfully even when the\nunderlying devices are in a suspended state.\n\nThis second patch uses md_is_rdwr() to distinguish between suspend and\ndestructor paths as elaborated on above.(CVE-2026-43309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: spidev: fix lock inversion between spi_lock and buf_lock\n\nThe spidev driver previously used two mutexes, spi_lock and buf_lock,\nbut acquired them in different orders depending on the code path:\n\n write()/read(): buf_lock -\u0026gt; spi_lock\n ioctl(): spi_lock -\u0026gt; buf_lock\n\nThis AB-BA locking pattern triggers lockdep warnings and can\ncause real deadlocks:\n\n WARNING: possible circular locking dependency detected\n spidev_ioctl() -\u0026gt; mutex_lock(\u0026amp;spidev-\u0026gt;buf_lock)\n spidev_sync_write() -\u0026gt; mutex_lock(\u0026amp;spidev-\u0026gt;spi_lock)\n *** DEADLOCK ***\n\nThe issue is reproducible with a simple userspace program that\nperforms write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from\nseparate threads on the same spidev file descriptor.\n\nFix this by simplifying the locking model and removing the lock\ninversion entirely. spidev_sync() no longer performs any locking,\nand all callers serialize access using spi_lock.\n\nbuf_lock is removed since its functionality is fully covered by\nspi_lock, eliminating the possibility of lock ordering issues.\n\nThis removes the lock inversion and prevents deadlocks without\nchanging userspace ABI or behaviour.(CVE-2026-43319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/fair: Fix zero_vruntime tracking fix\n\nJohn reported that stress-ng-yield could make his machine unhappy and\nmanaged to bisect it to commit b3d99f43c72b (\u0026quot;sched/fair: Fix\nzero_vruntime tracking\u0026quot;).\n\nThe combination of yield and that commit was specific enough to\nhypothesize the following scenario:\n\nSuppose we have 2 runnable tasks, both doing yield. Then one will be\neligible and one will not be, because the average position must be in\nbetween these two entities.\n\nTherefore, the runnable task will be eligible, and be promoted a full\nslice (all the tasks do is yield after all). This causes it to jump over\nthe other task and now the other task is eligible and current is no\nlonger. So we schedule.\n\nSince we are runnable, there is no {de,en}queue. All we have is the\n__{en,de}queue_entity() from {put_prev,set_next}_task(). But per the\nfingered commit, those two no longer move zero_vruntime.\n\nAll that moves zero_vruntime are tick and full {de,en}queue.\n\nThis means, that if the two tasks playing leapfrog can reach the\ncritical speed to reach the overflow point inside one tick\u0026apos;s worth of\ntime, we\u0026apos;re up a creek.\n\nAdditionally, when multiple cgroups are involved, there is no guarantee\nthe tick will in fact hit every cgroup in a timely manner. Statistically\nspeaking it will, but that same statistics does not rule out the\npossibility of one cgroup not getting a tick for a significant amount of\ntime -- however unlikely.\n\nTherefore, just like with the yield() case, force an update at the end\nof every slice. This ensures the update is never more than a single\nslice behind and the whole thing is within 2 lag bounds as per the\ncomment on entity_key().(CVE-2026-43323)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: require a full NFS mode SID before reading mode bits\n\nparse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS\nmode SID and reads sid.sub_auth[2] to recover the mode bits.\n\nThat assumes the ACE carries three subauthorities, but compare_sids()\nonly compares min(a, b) subauthorities. A malicious server can return\nan ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still\nmatches sid_unix_NFS_mode and then drives the sub_auth[2] read four\nbytes past the end of the ACE.\n\nRequire num_subauth \u0026gt;= 3 before treating the ACE as an NFS mode SID.\nThis keeps the fix local to the special-SID mode path without changing\ncompare_sids() semantics for the rest of cifsacl.(CVE-2026-43350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ne1000/e1000e: Fix leak in DMA error cleanup\n\nIf an error is encountered while mapping TX buffers, the driver should\nunmap any buffers already mapped for that skb.\n\nBecause count is incremented after a successful mapping, it will always\nmatch the correct number of unmappings needed when dma_error is reached.\nDecrementing count before the while loop in dma_error causes an\noff-by-one error. If any mapping was successful before an unsuccessful\nmapping, exactly one DMA mapping would leak.\n\nIn these commits, a faulty while condition caused an infinite loop in\ndma_error:\nCommit 03b1320dfcee (\u0026quot;e1000e: remove use of skb_dma_map from e1000e\ndriver\u0026quot;)\nCommit 602c0554d7b0 (\u0026quot;e1000: remove use of skb_dma_map from e1000 driver\u0026quot;)\n\nCommit c1fa347f20f1 (\u0026quot;e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of\nunsigned in *_tx_map()\u0026quot;) fixed the infinite loop, but introduced the\noff-by-one error.\n\nThis issue may still exist in the igbvf driver, but I did not address it\nin this patch.(CVE-2026-43445)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-pci: Fix race bug in nvme_poll_irqdisable()\n\nIn the following scenario, pdev can be disabled between (1) and (3) by\n(2). This sets pdev-\u0026gt;msix_enabled = 0. Then, pci_irq_vector() will\nreturn MSI-X IRQ(\u0026gt;15) for (1) whereas return INTx IRQ(\u0026lt;=15) for (2).\nThis causes IRQ warning because it tries to enable INTx IRQ that has\nnever been disabled before.\n\nTo fix this, save IRQ number into a local variable and ensure\ndisable_irq() and enable_irq() operate on the same IRQ number. Even if\npci_free_irq_vectors() frees the IRQ concurrently, disable_irq() and\nenable_irq() on a stale IRQ number is still valid and safe, and the\ndepth accounting reamins balanced.\n\ntask 1:\nnvme_poll_irqdisable()\n disable_irq(pci_irq_vector(pdev, nvmeq-\u0026gt;cq_vector)) ...(1)\n enable_irq(pci_irq_vector(pdev, nvmeq-\u0026gt;cq_vector)) ...(3)\n\ntask 2:\nnvme_reset_work()\n nvme_dev_disable()\n pdev-\u0026gt;msix_enable = 0; ...(2)\n\ncrash log:\n\n------------[ cut here ]------------\nUnbalanced enable for IRQ 10\nWARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26\nModules linked in:\nCPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: kblockd blk_mq_timeout_work\nRIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753\nCode: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c \u0026lt;67\u0026gt; 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9\nRSP: 0018:ffffc900001bf550 EFLAGS: 00010046\nRAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90\nRDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0\nRBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001\nR10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000\nR13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293\nFS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n enable_irq+0x121/0x1e0 kernel/irq/manage.c:797\n nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494\n nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744\n blk_mq_rq_timed_out block/blk-mq.c:1653 [inline]\n blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721\n bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292\n __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline]\n sbitmap_for_each_set include/linux/sbitmap.h:290 [inline]\n bt_for_each block/blk-mq-tag.c:324 [inline]\n blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536\n blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763\n process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257\n process_scheduled_works kernel/workqueue.c:3340 [inline]\n worker_thread+0x65c/0xe60 kernel/workqueue.c:3421\n kthread+0x41a/0x930 kernel/kthread.c:463\n ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n \u0026lt;/TASK\u0026gt;\nirq event stamp: 74478\nhardirqs last enabled at (74477): [\u0026lt;ffffffffb5720a9c\u0026gt;] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline]\nhardirqs last enabled at (74477): [\u0026lt;ffffffffb5720a9c\u0026gt;] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202\nhardirqs last disabled at (74478): [\u0026lt;ffffffffb57207b5\u0026gt;] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]\nhardirqs last disabled at (74478): [\u0026lt;ffffffffb57207b5\u0026gt;] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162\nsoftirqs last enabled at (74304): [\u0026lt;ffffffffb1e9466c\u0026gt;] __do_softirq kernel/softirq.c:656 [inline]\nsoftirqs last enabled at (74304): [\u0026lt;ffffffffb1e9466c\u0026gt;] invoke_softirq kernel/softirq.c:496 [inline]\nsoftirqs last enabled at (74304): [\u0026lt;ffffffffb1e9466c\u0026gt;] __irq_exit_rcu+0xdc/0x120\n---truncated---(CVE-2026-43448)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation\n\nUlrich reports a regression with nfqueue:\n\nIf an application did not set the \u0026apos;F_GSO\u0026apos; capability flag and a gso\npacket with an unconfirmed nf_conn entry is received all packets are\nnow dropped instead of queued, because the check happens after\nskb_gso_segment(). In that case, we did have exclusive ownership\nof the skb and its associated conntrack entry. The elevated use\ncount is due to skb_clone happening via skb_gso_segment().\n\nMove the check so that its peformed vs. the aggregated packet.\n\nThen, annotate the individual segments except the first one so we\ncan do a 2nd check at reinject time.\n\nFor the normal case, where userspace does in-order reinjects, this avoids\npacket drops: first reinjected segment continues traversal and confirms\nentry, remaining segments observe the confirmed entry.\n\nWhile at it, simplify nf_ct_drop_unconfirmed(): We only care about\nunconfirmed entries with a refcnt \u0026gt; 1, there is no need to special-case\ndying entries.\n\nThis only happens with UDP. With TCP, the only unconfirmed packet will\nbe the TCP SYN, those aren\u0026apos;t aggregated by GRO.\n\nNext patch adds a udpgro test case to cover this scenario.(CVE-2026-45859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Add missing save/restore handling of LBR MSRs\n\nMSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by\nKVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So\nsave/restore is completely broken.\n\nFix it by adding the MSRs to msrs_to_save_base, and allowing writes to\nLBR MSRs from userspace only (as they are read-only MSRs) if LBR\nvirtualization is enabled. Additionally, to correctly restore L1\u0026apos;s LBRs\nwhile L2 is running, make sure the LBRs are copied from the captured\nVMCB01 save area in svm_copy_vmrun_state().\n\nNote, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn\u0026apos;t\nreported as an MSR to save/restore.\n\nNote #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already\nhandles unsupported reads and writes thanks to commit b5e2fec0ebc3 (\u0026quot;KVM:\nIgnore DEBUGCTL MSRs with no effect\u0026quot;) (kvm_do_msr_access() will morph the\nunsupported userspace write into a nop).\n\n[sean: guard with lbrv checks, massage changelog](CVE-2026-46014)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/CPU/AMD: Prevent improper isolation of shared resources in Zen2\u0026apos;s op cache\n\nMake sure resources are not improperly shared in the op cache and\ncause instruction corruption this way.(CVE-2026-46174)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_inner: Fix IPv6 inner_thoff desync\n\nIn nft_inner_parse_l2l3(), when processing inner IPv6 packets,\nipv6_find_hdr() correctly computes the transport header offset\ntraversing all extension headers, but the result is immediately\noverwritten with nhoff + sizeof(_ip6h) (40 bytes), which only\naccounts for the IPv6 base header. This creates a desync between\ninner_thoff (wrong \u2014 points to extension header start) and l4proto\n(correct \u2014 e.g., IPPROTO_TCP), enabling transport header forgery\nand potential firewall bypass. This issue affects stable versions\nfrom Linux 6.2.\n\nFor comparison, the normal (non-inner) IPv6 path correctly\npreserves ipv6_find_hdr()\u0026apos;s result. Removing the incorrect overwrite\nensures that ipv6_find_hdr()\u0026apos;s calculated transport header offset is\npreserved, thereby fixing the desynchronization.(CVE-2026-46244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntap: free page on error paths in tap_get_user_xdp()\n\ntap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL,\nand returns -ENOMEM when build_skb() fails. Both paths jump to the err\nlabel without freeing the page that vhost_net_build_xdp() allocated for\nthe frame. tap_sendmsg() discards the per-buffer return value and always\nreturns 0, so vhost_tx_batch() takes the success path and never frees\nthe page; each rejected frame in a batch leaks one page-frag chunk.\n\nFree the page on both error paths, before the skb is built. This is the\ntap counterpart of the same leak in tun_xdp_one().(CVE-2026-46320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntun: free page on short-frame rejection in tun_xdp_one()\n\ntun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without\nfreeing the page that vhost_net_build_xdp() allocated for it.\ntun_sendmsg() discards that -EINVAL and still returns total_len, so\nvhost_tx_batch() takes the success path and never frees the page; each\nshort frame in a batch leaks one page-frag chunk.\n\nA local process that can open /dev/net/tun and /dev/vhost-net can hit\nthis path: it attaches a tun/tap device as the vhost-net backend and\nfeeds TX descriptors whose length minus the virtio-net header is below\nETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a\ntight submission loop exhausts host memory and triggers an OOM panic.\nFree the page before returning -EINVAL, matching the XDP-program error\npath in the same function.(CVE-2026-46321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntun: free page on build_skb failure in tun_xdp_one()\n\nWhen build_skb() fails in tun_xdp_one(), the function sets ret to\n-ENOMEM and jumps to the out label, which returns without freeing the\npage that vhost_net_build_xdp() allocated for the frame. As with the\nshort-frame rejection path, tun_sendmsg() discards the per-buffer error\nand still returns total_len, so vhost_tx_batch() takes the success path\nand never frees the page. Each build_skb() failure in a batch leaks one\npage-frag chunk.\n\nFree the page before taking the error path, matching the put_page() the\nother error exits of tun_xdp_one() already perform.(CVE-2026-46322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: gro: don\u0026apos;t merge zcopy skbs\n\nskb_gro_receive() can currently copy frags between the source and GRO\nskb, without checking the zerocopy status, and in particular the\nSKBFL_MANAGED_FRAG_REFS flag.\n\nWhen SKBFL_MANAGED_FRAG_REFS is set, the skb doesn\u0026apos;t hold a reference\non the pages in shinfo-\u0026gt;frags. Appending those frags to another skb\u0026apos;s\nfrags without fixing up the page refcount can lead to UAF.\n\nWhen either the last skb in the GRO chain (the one we would append\nfrags to) or the source skb is zerocopy, don\u0026apos;t merge the skbs.(CVE-2026-46323)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRevert \u0026quot;net/smc: Introduce TCP ULP support\u0026quot;\n\nThis reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.\n\nAs reported by Al Viro, the TCP ULP support for SMC is fundamentally\nbroken. The implementation attempts to convert an active TCP socket\ninto an SMC socket by modifying the underlying `struct file`, dentry,\nand inode in-place, which violates core VFS invariants that assume\nthese structures are immutable for an open file, creating a risk of\nuse after free errors and general system instability.\n\nGiven the severity of this design flaw and the fact that cleaner\nalternatives (e.g., LD_PRELOAD, BPF) exist for legacy application\ntransparency, the correct course of action is to remove this feature\nentirely.(CVE-2026-46330)",
"id": "OESA-2026-2869",
"modified": "2026-08-06T11:11:46Z",
"published": "2026-07-06T11:11:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2869"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10263"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39932"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71203"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23261"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23346"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23377"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31414"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31432"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31440"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31443"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31453"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31466"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31508"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31551"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31557"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31580"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31663"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31681"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31717"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43025"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43026"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43116"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43125"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43127"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43220"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43239"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43309"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43323"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43445"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43448"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46014"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46174"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46320"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46321"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46322"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46323"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46330"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-10263",
"CVE-2025-39932",
"CVE-2025-71203",
"CVE-2026-23261",
"CVE-2026-23346",
"CVE-2026-23377",
"CVE-2026-31414",
"CVE-2026-31432",
"CVE-2026-31440",
"CVE-2026-31443",
"CVE-2026-31453",
"CVE-2026-31466",
"CVE-2026-31508",
"CVE-2026-31551",
"CVE-2026-31557",
"CVE-2026-31580",
"CVE-2026-31663",
"CVE-2026-31664",
"CVE-2026-31681",
"CVE-2026-31717",
"CVE-2026-31725",
"CVE-2026-43022",
"CVE-2026-43025",
"CVE-2026-43026",
"CVE-2026-43091",
"CVE-2026-43116",
"CVE-2026-43125",
"CVE-2026-43127",
"CVE-2026-43220",
"CVE-2026-43239",
"CVE-2026-43309",
"CVE-2026-43319",
"CVE-2026-43323",
"CVE-2026-43350",
"CVE-2026-43445",
"CVE-2026-43448",
"CVE-2026-45859",
"CVE-2026-46014",
"CVE-2026-46174",
"CVE-2026-46244",
"CVE-2026-46320",
"CVE-2026-46321",
"CVE-2026-46322",
"CVE-2026-46323",
"CVE-2026-46330"
]
}
OESA-2026-3204 (CVE-2025-71273)
Vulnerability from osv_openeuler – Published: 2026-08-01 11:12 – Updated: 2026-08-06 11:12 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band()
Simplify the code by using device managed memory allocations.
This also fixes a memory leak in rtw_register_hw(). The supported bands were not freed in the error path.
Copied from commit 145df52a8671 ("wifi: rtw89: Convert rtw89_core_set_supported_band to use devm_*").(CVE-2025-71273)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: hold dev ref until after transport_finish NF_HOOK
After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown.
Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn.
For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.(CVE-2026-31663)
In the Linux kernel, the following vulnerability has been resolved:
x86: shadow stacks: proper error handling for mmap lock
김영민 reports that shstk_pop_sigframe() doesn't check for errors from mmap_read_lock_killable(), which is a silly oversight, and also shows that we haven't marked those functions with "__must_check", which would have immediately caught it.
So let's fix both issues.(CVE-2026-43109)
In the Linux kernel, the following vulnerability has been resolved:
srcu: Use irq_work to start GP in tiny SRCU
Tiny SRCU's srcu_gp_start_if_needed() directly calls schedule_work(), which acquires the workqueue pool->lock.
This causes a lockdep splat when call_srcu() is called with a scheduler lock held, due to:
call_srcu() [holding pi_lock] srcu_gp_start_if_needed() schedule_work() -> pool->lock
workqueue_init() / create_worker() [holding pool->lock] wake_up_process() -> try_to_wake_up() -> pi_lock
Also add irq_work_sync() to cleanup_srcu_struct() to prevent a use-after-free if a queued irq_work fires after cleanup begins.
Tested with rcutorture SRCU-T and no lockdep warnings.
Thanks to Boqun for similar fix in patch "rcu: Use an intermediate irq_work to start process_srcu()"
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: fix 22000 series SMEM parsing
If the firmware were to report three LMACs (which doesn't exist in hardware) then using "fwrt->smem_cfg.lmac[2]" is an overrun of the array. Reject such and use IWL_FW_CHECK instead of WARN_ON in this function.(CVE-2026-43172)
In the Linux kernel, the following vulnerability has been resolved:
bonding: fix type confusion in bond_setup_by_slave()
kernel BUG at net/core/skbuff.c:2306! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306 RSP: 0018:ffffc90004aff760 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900 RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780 R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0 Call Trace: <TASK> ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900 dev_hard_header include/linux/netdevice.h:3439 [inline] packet_snd net/packet/af_packet.c:3028 [inline] packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] _syssendmsg+0xa54/0xc30 net/socket.c:2592 _sys_sendmsg+0x190/0x1e0 net/socket.c:2646 __sys_sendmsg+0x170/0x220 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe1a0e6c1a9
When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond, bond_setup_by_slave() directly copies the slave's header_ops to the bond device:
bond_dev->header_ops = slave_dev->header_ops;
This causes a type confusion when dev_hard_header() is later called on the bond device. Functions like ipgre_header(), ip6gre_header(),all use netdev_priv(dev) to access their device-specific private data. When called with the bond device, netdev_priv() returns the bond's private data (struct bonding) instead of the expected type (e.g. struct ip_tunnel), leading to garbage values being read and kernel crashes.
Fix this by introducing bond_header_ops with wrapper functions that delegate to the active slave's header_ops using the slave's own device. This ensures netdev_priv() in the slave's header functions always receives the correct device.
The fix is placed in the bonding driver rather than individual device drivers, as the root cause is bond blindly inheriting header_ops from the slave without considering that these callbacks expect a specific netdev_priv() layout.
The type confusion can be observed by adding a printk in ipgre_header() and running the following commands:
ip link add dummy0 type dummy
ip addr add 10.0.0.1/24 dev dummy0
ip link set dummy0 up
ip link add gre1 type gre local 10.0.0.1
ip link add bond1 type bond mode active-backup
ip link set gre1 master bond1
ip link set gre1 up
ip link set bond1 up
ip addr add fe80::1/64 dev bond1(CVE-2026-43456)
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-scsi: avoid Non-NCQ command starvation
When a non-NCQ command is issued while NCQ commands are being executed, ata_scsi_qc_issue() indicates to the SCSI layer that the command issuing should be deferred by returning SCSI_MLQUEUE_XXX_BUSY. This command deferring is correct and as mandated by the ACS specifications since NCQ and non-NCQ commands cannot be mixed.
However, in the case of a host adapter using multiple submission queues, when the target device is under a constant load of NCQ commands, there are no guarantees that requeueing the non-NCQ command will be executed later and it may be deferred again repeatedly as other submission queues can constantly issue NCQ commands from different CPUs ahead of the non-NCQ command. This can lead to very long delays for the execution of non-NCQ commands, and even complete starvation for these commands in the worst case scenario.
Since the block layer and the SCSI layer do not distinguish between queueable (NCQ) and non queueable (non-NCQ) commands, libata-scsi SAT implementation must ensure forward progress for non-NCQ commands in the presence of NCQ command traffic. This is similar to what SAS HBAs with a hardware/firmware based SAT implementation do.
Implement such forward progress guarantee by limiting requeueing of non-NCQ commands from ata_scsi_qc_issue(): when a non-NCQ command is received and NCQ commands are in-flight, do not force a requeue of the non-NCQ command by returning SCSI_MLQUEUE_XXX_BUSY and instead return 0 to indicate that the command was accepted but hold on to the qc using the new deferred_qc field of struct ata_port.
This deferred qc will be issued using the work item deferred_qc_work running the function ata_scsi_deferred_qc_work() once all in-flight commands complete, which is checked with the port qc_defer() callback return value indicating that no further delay is necessary. This check is done using the helper function ata_scsi_schedule_deferred_qc() which is called from ata_scsi_qc_complete(). This thus excludes this mechanism from all internal non-NCQ commands issued by ATA EH.
When a port deferred_qc is non NULL, that is, the port has a command waiting for the device queue to drain, the issuing of all incoming commands (both NCQ and non-NCQ) is deferred using the regular busy mechanism. This simplifies the code and also avoids potential denial of service problems if a user issues too many non-NCQ commands.
Finally, whenever ata EH is scheduled, regardless of the reason, a deferred qc is always requeued so that it can be retried once EH completes. This is done by calling the function ata_scsi_requeue_deferred_qc() from ata_eh_set_pending(). This avoids the need for any special processing for the deferred qc in case of NCQ error, link or device reset, or device timeout.(CVE-2026-45855)
In the Linux kernel, the following vulnerability has been resolved:
ext4: drop extent cache when splitting extent fails
When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails.(CVE-2026-45899)
In the Linux kernel, the following vulnerability has been resolved:
selinux: fix overlayfs mmap() and mprotect() access checks
The existing SELinux security model for overlayfs is to allow access if the current task is able to access the top level file (the "user" file) and the mounter's credentials are sufficient to access the lower level file (the "backing" file). Unfortunately, the current code does not properly enforce these access controls for both mmap() and mprotect() operations on overlayfs filesystems.
This patch makes use of the newly created security_mmap_backing_file() LSM hook to provide the missing backing file enforcement for mmap() operations, and leverages the backing file API and new LSM blob to provide the necessary information to properly enforce the mprotect() access controls.(CVE-2026-46054)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: ADD_ADDR rtx: always decrease sk refcount
When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end.
Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak.
While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as "unlikely".(CVE-2026-46158)
In the Linux kernel, the following vulnerability has been resolved:
selinux: allow multiple opens of /sys/fs/selinux/policy
Currently there can only be a single open of /sys/fs/selinux/policy at any time. This allows any process to block any other process from reading the kernel policy. The original motivation seems to have been a mix of preventing an inconsistent view of the policy size and preventing userspace from allocating kernel memory without bound, but this is arguably equally bad. Eliminate the policy_opened flag and shrink the critical section that the policy mutex is held. While we are making changes here, drop a couple of extraneous BUG_ONs.(CVE-2026-46302)
In the Linux kernel, the following vulnerability has been resolved:
ip6_vti: set netns_immutable on the fallback device.
john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0).
Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.(CVE-2026-52909)
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: fix missing zerocopy reference in pskb_carve helpers
pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers.
KASAN reports use-after-free on a freed ubuf_info_msgzc:
BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220
Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180
Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0
Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530
The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration.
The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().(CVE-2026-52943)
In the Linux kernel, the following vulnerability has been resolved:
fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in send_sigio() and send_sigurg() when a process group receives a signal.
When FASYNC is configured for a process group (PIDTYPE_PGID), both functions use read_lock(&tasklist_lock) to traverse the task list. However, they are frequently called from softirq context: - send_sigio() via input_inject_event -> kill_fasync - send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ)
The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait(). 2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in fork() or exit() and spins, which blocks all new readers. 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception). 4. The softirq calls send_sigurg() and attempts to acquire read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.
Since PID hashing and do_each_pid_task() traversals are already RCU-protected, the read_lock on tasklist_lock is no longer strictly required for safe traversal. Fix this by replacing tasklist_lock with rcu_read_lock(), aligning the process group signaling path with the single-PID path. This also mitigates a potential remote denial of service vector via TCP URG packets.
Lockdep splat:
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [...] Chain exists of: &dev->event_lock --> &f_owner->lock --> tasklist_lock
Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklist_lock); local_irq_disable(); lock(&dev->event_lock); lock(&f_owner->lock); <Interrupt> lock(&dev->event_lock);
*** DEADLOCK ***(CVE-2026-52946)
In the Linux kernel, the following vulnerability has been resolved:
smb/client: fix possible infinite loop and oob read in symlink_data()
On 32-bit architectures, the infinite loop is as follows:
len = p->ErrorDataLength == 0xfffffff8 u8 *next = p->ErrorContextData + len next == p
On 32-bit architectures, the out-of-bounds read is as follows:
len = p->ErrorDataLength == 0xfffffff0 u8 next = p->ErrorContextData + len next == (u8 )p - 8(CVE-2026-52967)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase
Publish new hooks in the list into the basechain/flowtable using splice_list_rcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on.(CVE-2026-52988)
In the Linux kernel, the following vulnerability has been resolved:
sched/psi: fix race between file release and pressure write
A potential race condition exists between pressure write and cgroup file release regarding the priv member of struct kernfs_open_file, which triggers the uaf reported in 1.
Consider the following scenario involving execution on two separate CPUs:
CPU0 CPU1 ==== ==== vfs_rmdir() kernfs_iop_rmdir() cgroup_rmdir() cgroup_kn_lock_live() cgroup_destroy_locked() cgroup_addrm_files() cgroup_rm_file() kernfs_remove_by_name() kernfs_remove_by_name_ns() vfs_write() __kernfs_remove() new_sync_write() kernfs_drain() kernfs_fop_write_iter() kernfs_drain_open_files() cgroup_file_write() kernfs_release_file() pressure_write() cgroup_file_release() ctx = of->priv; kfree(ctx); of->priv = NULL; cgroup_kn_unlock() cgroup_kn_lock_live() cgroup_get(cgrp) cgroup_kn_unlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->priv
The cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards the memory deallocation of of->priv performed within cgroup_file_release(). However, the operations involving of->priv executed within pressure_write() are not entirely covered by the protection of cgroup_mutex. Consequently, if the code in pressure_write(), specifically the section handling the ctx variable executes after cgroup_file_release() has completed, a uaf vulnerability involving of->priv is triggered.
Therefore, the issue can be resolved by extending the scope of the cgroup_mutex lock within pressure_write() to encompass all code paths involving of->priv, thereby properly synchronizing the race condition occurring between cgroup_file_release() and pressure_write().
And, if an live kn lock can be successfully acquired while executing the pressure write operation, it indicates that the cgroup deletion process has not yet reached its final stage; consequently, the priv pointer within open_file cannot be NULL. Therefore, the operation to retrieve the ctx value must be moved to a point after the live kn lock has been successfully acquired.
In another situation, specifically after entering cgroup_kn_lock_live() but before acquiring cgroup_mutex, there exists a different class of race condition:
CPU0: write memory.pressure CPU1: write cgroup.pressure=0 =========================== =============================
kernfs_fop_write_iter() kernfs_get_active_of(of) pressure_write() cgroup_kn_lock_live(memory.pressure) cgroup_tryget(cgrp) kernfs_break_active_protection(kn) ... blocks on cgroup_mutex
cgroup_pressure_write()
cgroup_kn_lock_live(cgroup.pressure)
cgroup_file_show(memory.pressure, false)
kernfs_show(false)
kernfs_drain_open_files()
cgroup_file_release(of)
kfree(ctx)
of->priv = NULL
cgroup_kn_unlock()
... acquires cgroup_mutex ctx = of->priv; // may now be NULL if (ctx->psi.trigger) // NULL dereference
Consequently, there is a possibility that of->priv is NULL, the pressure write needs to check for this.
Now that the scope of the cgroup_mutex has been expanded, the original explicit cgroup_get/put operations are no longer necessary, this is because acquiring/releasing the live kn lock inherently executes a cgroup get/put operation.
1 BUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 Call Trace: pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43 ---truncated---(CVE-2026-52991)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nat: use kfree_rcu to release ops
Florian Westphal says:
"Historically this is not an issue, even for normal base hooks: the data path doesn't use the original nf_hook_ops that are used to register the callbacks.
However, in v5.14 I added the ability to dump the active netfilter hooks from userspace.
This code will peek back into the nf_hook_ops that are available at the tail of the pointer-array blob used by the datapath.
The nat hooks are special, because they are called indirectly from the central nat dispatcher hook. They are currently invisible to the nfnl hook dump subsystem though.
But once that changes the nat ops structures have to be deferred too."
Update nf_nat_register_fn() to deal with partial exposition of the hooks from error path which can be also an issue for nfnetlink_hook.(CVE-2026-53000)
In the Linux kernel, the following vulnerability has been resolved:
pppoe: drop PFC frames
RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the current PPPoE driver assumes an uncompressed (2-byte) protocol field. However, the generic PPP layer function ppp_input() is not aware of the negotiation result, and still accepts PFC frames.
If a peer with a broken implementation or an attacker sends a frame with a compressed (1-byte) protocol field, the subsequent PPP payload is shifted by one byte. This causes the network header to be 4-byte misaligned, which may trigger unaligned access exceptions on some architectures.
To reduce the attack surface, drop PPPoE PFC frames. Introduce ppp_skb_is_compressed_proto() helper function to be used in both ppp_generic.c and pppoe.c to avoid open-coding.(CVE-2026-53003)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp
l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it.
Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(), and l2cap_chan_unlock() and l2cap_chan_put() after, matching the pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().(CVE-2026-53071)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER
When protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls hci_connect_cfm(conn) without hdev->lock. Generally hci_connect_cfm() assumes it is held, and if conn is deleted concurrently -> UAF.
Only SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen, and HCI_EV_CONN_REQUEST is not generated for ISO. In the non-deferred listening socket code paths, hci_connect_cfm(conn) is called with hdev->lock held.
Fix by holding the lock.(CVE-2026-53072)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix ld_{abs,ind} failure path analysis in subprogs
Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 ("bpf: Add abnormal return checks."). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types.
The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed.
This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.(CVE-2026-53090)
In the Linux kernel, the following vulnerability has been resolved:
md: wake raid456 reshape waiters before suspend
During raid456 reshape, direct IO across the reshape position can sleep in raid5_make_request() waiting for reshape progress while still holding an active_io reference. If userspace then freezes reshape and writes md/suspend_lo or md/suspend_hi, mddev_suspend() kills active_io and waits for all in-flight IO to drain.
This can deadlock: the IO needs reshape progress to continue, but the reshape thread is already frozen, so the active_io reference is never dropped and suspend never completes.
raid5_prepare_suspend() already wakes wait_for_reshape for dm-raid. Do the same for normal md suspend when reshape is already interrupted, so waiting raid456 IO can abort, drop its reference, and let suspend finish.
The mdadm test tests/25raid456-reshape-deadlock reproduces the hang.(CVE-2026-53123)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: require Ethernet MAC header before using eth_hdr()
ip6t_eui64, xt_mac, the bitmap:ip,mac, hash:ip,mac, and
hash:mac ipset types, and nf_log_syslog access eth_hdr(skb)
after either assuming that the skb is associated with an Ethernet
device or checking only that the ETH_HLEN bytes at
skb_mac_header(skb) lie between skb->head and skb->data.
Make these paths first verify that the skb is associated with an
Ethernet device, that the MAC header was set, and that it spans at
least a full Ethernet header before accessing eth_hdr(skb).(CVE-2026-53131)
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: fix potential unbounded skb queue
virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM.
If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0.
Fix this by estimating the skb metadata size:
(Number of skbs in the queue) * SKB_TRUESIZE(0)(CVE-2026-53132)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_fib: fix stale stack leak via the OIFNAME register
For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via "*dest = 0". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace.
The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale.
Fix both:
-
replace the bare "*dest = 0" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and
-
restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.(CVE-2026-53134)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Clamp VBIOS HDMI retimer register count to array size
[Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp_ext_hdmi_reg_settings[9] and dp_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe.
Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1().
(cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)(CVE-2026-53136)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size
[Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read.
Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch.
(cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)(CVE-2026-53137)
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Bound root directory content to block size
__tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block.
Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.(CVE-2026-53149)
In the Linux kernel, the following vulnerability has been resolved:
inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush
On netns teardown, fqdir_pre_exit() walks the fqdir rhashtable and flushes every fragment queue that is not yet complete using inet_frag_queue_flush(). That helper frees all the skbs queued on the fragment queue but does not set INET_FRAG_COMPLETE, and leaves q->fragments_tail and q->last_run_head pointing at the freed skbs. The queue itself stays in the rhashtable.
fqdir_pre_exit() first lowers high_thresh to 0 to stop new queue lookups, but it cannot stop a fragment that already obtained the queue through inet_frag_find() earlier and stalled just before taking the queue lock. Once that fragment resumes after the flush and takes the queue lock, it passes the INET_FRAG_COMPLETE check and then dereferences the freed fragments_tail. inet_frag_queue_insert() reads FRAG_CB() and ->len of that pointer and, on the append path, writes ->next_frag, causing a slab use-after-free. IPv6, nf_conntrack_reasm6 and 6lowpan reassembly share the same flush path and are affected as well.
Reset rb_fragments, fragments_tail and last_run_head in inet_frag_queue_flush() so a flushed queue no longer points at the freed skbs. A fragment that resumes after the flush and takes the queue lock then finds an empty queue and starts a new run instead of dereferencing the freed fragments_tail. ip_frag_reinit() already performed this reset after its own flush, so drop the now duplicate code there.(CVE-2026-53175)
In the Linux kernel, the following vulnerability has been resolved:
IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN
In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative.
isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path.
Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added.(CVE-2026-53176)
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix NULL pointer dereference
PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state.
The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi.
Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer.
Check if bp->bnapi is NULL before disabling and synchronizing IRQs.(CVE-2026-53177)
In the Linux kernel, the following vulnerability has been resolved:
udp: clear skb->dev before running a sockmap verdict
On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff.
When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does:
if (skb->dev)
caller_net = dev_net(skb->dev);
skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq:
Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: <IRQ> bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 </IRQ>
The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.(CVE-2026-53184)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srp: bound SRP_RSP sense copy by the received length
srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded.
A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults.
Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.(CVE-2026-53186)
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait()
dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put().
When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each.
Add dma_fence_put(itr.chain) before the early return.(CVE-2026-53190)
In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison
Two concurrent madvise(MADV_HWPOISON) calls on the same hugetlb page can trigger a recursive spinlock self-deadlock (AA deadlock) on hugetlb_lock when racing with a concurrent unmap:
thread#0 thread#1 -------- -------- madvise(folio, MADV_HWPOISON) -> poisons the folio successfully madvise(folio, MADV_HWPOISON) unmap(folio) try_memory_failure_hugetlb get_huge_page_for_hwpoison spin_lock_irq(&hugetlb_lock) <- held __get_huge_page_for_hwpoison hugetlb_update_hwpoison() -> MF_HUGETLB_FOLIO_PRE_POISONED goto out: folio_put() refcount: 1 -> 0 free_huge_folio() spin_lock_irqsave(&hugetlb_lock) -> AA DEADLOCK!
The out: path in __get_huge_page_for_hwpoison() calls folio_put() to drop the GUP reference while the hugetlb_lock is still held by the hugetlb.c wrapper get_huge_page_for_hwpoison(). If concurrent unmap has released the page table mapping reference, folio_put() drops the folio refcount to zero, triggering free_huge_folio() which attempts to re-acquire the non-recursive hugetlb_lock.
Fix this by moving hugetlb_lock acquisition from the hugetlb.c wrapper into get_huge_page_for_hwpoison(). Place spin_unlock_irq() before the folio_put() at the out: label so the folio is always released outside the lock.
[(CVE-2026-53207)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_exthdr: fix register tracking for F_PRESENT flag
nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs.
Bail out if userspace requests too much data when F_PRESENT is set.(CVE-2026-53218)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: x_tables: avoid leaking percpu counter pointers
The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot.
On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace.
Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.(CVE-2026-53219)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: revalidate bridge ports
ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject.
A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan.
If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path.
Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact:
Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off.
Fixes tag is a common ancestor, this was always broken.(CVE-2026-53220)
In the Linux kernel, the following vulnerability has been resolved:
ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()
In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels:
-
Tunnels matching the packet's local address, with any remote address wildcard remote).
-
Tunnels matching the packet's remote address, with any local address (wildcard local).
However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions.
The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.(CVE-2026-53221)
In the Linux kernel, the following vulnerability has been resolved:
net: guard timestamp cmsgs to real error queue skbs
skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb.
If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents.
Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.(CVE-2026-53223)
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix possible kfree_skb of ERR_PTR
After the patch in the "Fixes" tag, the allocation of the "reply" skb can happen either before or after locking the ovs_mutex.
However, error cleanups still follow the classical reversed order, assuming "reply" is allocated before locking: it is freed after unlocking.
If "reply" allocation happens after locking the mutex and it fails, "reply" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer.
Fix this by setting the pointer to NULL after having saved its error value.(CVE-2026-53227)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sit: reload inner IPv6 header after GSO offloads
ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads().
For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call.
If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released.
Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb.(CVE-2026-53228)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure
In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries.
With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind:
DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core]
Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.(CVE-2026-53229)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list
mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer:
BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385
CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: <TASK> dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 </TASK>
Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.(CVE-2026-53230)
In the Linux kernel, the following vulnerability has been resolved:
tcp: restrict SO_ATTACH_FILTER to priv users
This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability.
This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.(CVE-2026-53236)
In the Linux kernel, the following vulnerability has been resolved:
netlabel: validate unlabeled address and mask attribute lengths
netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr.
NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.(CVE-2026-53238)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx()
Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed.
Race:
CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed(CVE-2026-53239)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams
snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic.
Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.(CVE-2026-53242)
In the Linux kernel, the following vulnerability has been resolved:
net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr
In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process.
The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state.
Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing.
Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value.
Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.(CVE-2026-53245)
In the Linux kernel, the following vulnerability has been resolved:
sctp: validate cached peer INIT chunk length in COOKIE_ECHO processing
When a listening SCTP server processes a COOKIE_ECHO chunk, the cached peer INIT chunk embedded after the cookie is parsed and its parameters are later walked by sctp_process_init() using sctp_walk_params().
However, the chunk header length of this cached INIT chunk was not validated against the remaining buffer in the COOKIE_ECHO payload. If the length field is inflated, the parameter walk can run beyond the actual received data, leading to out-of-bounds reads and potential memory corruption during later parameter handling (e.g. STATE_COOKIE processing and kmemdup() copies).
Add a bounds check in sctp_unpack_cookie() to ensure the cached INIT chunk length does not exceed the available data in the COOKIE_ECHO buffer before it is used.(CVE-2026-53246)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options
This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability.
This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information.
While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths.
RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.(CVE-2026-53249)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix memory leak in error path of hci_alloc_dev()
Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory.
When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev).
Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory.
Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.(CVE-2026-53252)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: bnep: reject short frames before parsing
A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload.
Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads.
For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication.
Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)(CVE-2026-53253)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: validate skb length in MCC handlers
The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers.
Fix this by using skb_pull_data() to validate and access the required data before dereferencing it.
rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.(CVE-2026-53254)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: validate advertising TLV before type checks
tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer.
A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data.
KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path:
BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg()
Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].(CVE-2026-53255)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()
rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it.
The buggy scenario involves two paths, with each column showing the order within that path:
rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change().
If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback.
Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use.
KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().(CVE-2026-53256)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_api: use RCU with deferred freeing for action lifecycle
When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action.
Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER:
0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory
This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree().
Note: this is a revert of commit d7fb60b9cafb ("net_sched: get rid of tcfa_rcu") but also modernization/simplification to directly use kfree_rcu().
Let's illustrate the new restored code path:
0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period
After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.(CVE-2026-53264)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: make ebt_snat ARP rewrite writable
The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a.
However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data:
skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN)
skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it.
Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().(CVE-2026-53266)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_ct: bail out on template ct in get eval
I noticed this issue while looking at a historic syzbot report 1.
A rule like the one below is enough to trigger the bug:
table ip t {
chain pre {
type filter hook prerouting priority raw;
ct zone set 1
ct original saddr 1.2.3.4 accept
}
}
The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers.
Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: synproxy: add mutex to guard hook reference counting
As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other.
Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.(CVE-2026-53269)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: clear the svc scheduler ptr early on edit
ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period.
Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks.
Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.(CVE-2026-53270)
In the Linux kernel, the following vulnerability has been resolved:
net: bonding: fix NULL pointer dereference in bond_do_ioctl()
In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check:
slave_dev = __dev_get_by_name(net, ifr->ifr_slave);
slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here
if (!slave_dev)
return -ENODEV;
The slave_dbg() macro expands to netdev_dbg(bond_dev, "(slave %s): " fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name.
This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector.
Fix by moving the slave_dbg() call after the NULL check.(CVE-2026-53337)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack: destroy stale expectfn expectations on unregister
NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text.
When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port:
Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323]
Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless.
Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.(CVE-2026-53349)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()
bt_accept_dequeue() unlinks a not-yet-accepted child from the parent accept queue and release_sock()s it before returning, so the returned sk has no caller reference and is unlocked.
l2cap_sock_cleanup_listen() walks these children on listening-socket close. A concurrent HCI disconnect drives hci_rx_work -> l2cap_conn_del() which runs l2cap_chan_del() + l2cap_sock_kill() and frees the child sk and its l2cap_chan; cleanup_listen() then uses both:
BUG: KASAN: slab-use-after-free in l2cap_sock_kill l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close Freed by: l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill
This is distinct from the two fixes already in this area: commit e83f5e24da741 ("Bluetooth: serialize accept_q access") serialises the accept_q list/poll and takes temporary refs inside bt_accept_dequeue(), and CVE-2025-39860 serialises the userspace close()/accept() race by calling cleanup_listen() under lock_sock() in l2cap_sock_release(). Neither covers l2cap_conn_del() running from hci_rx_work, so this UAF still reproduces on current bluetooth/master.
Take the reference at the source: bt_accept_dequeue() does sock_hold() while sk is still locked, before release_sock(); callers sock_put(). cleanup_listen() pins the chan with l2cap_chan_hold_unless_zero() under a brief child sk lock (serialising vs l2cap_sock_teardown_cb()), drops it before l2cap_chan_lock(), and skips a duplicate l2cap_sock_kill() on SOCK_DEAD. conn->lock is not taken here: cleanup_listen() runs under the parent sk lock and that would invert conn->lock -> chan->lock -> sk_lock (lockdep).
KASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced 12 use-after-free reports per run before this change; 0, and no lockdep report, over 1600+ raced iterations after it on bluetooth/master.(CVE-2026-53357)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()
l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order.
Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order.
The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.(CVE-2026-53358)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix shadow paging use-after-free due to unexpected role
Commit 0cb2af2ea66ad ("KVM: x86: Fix shadow paging use-after-free due to unexpected GFN") fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmap_remove() call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the GFN of the struct kvm_mmu_page.
A similar hole however remains if the modified PDE points to a non-leaf page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page creates a kvm_mmu_page with direct=1, while the new 4KB needs a kvm_mmu_page with direct=0. However, kvm_mmu_get_child_sp() does not compare the role, and therefore reuses the page.
The next step is installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the walk. But when that child is zapped its parent kvm_mmu_page has direct=1 and kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[] in older kernels). It therefore fails to remove the recorded entry.
When the memslot is dropped the shadow page is freed but the rmap entry survives, as in the scenario that was already fixed. Code that later walks that gfn (dirty logging, MMU notifier invalidation, and so on) dereferences an sptep that lies in the freed page, causing the use-after-free.(CVE-2026-53359)
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: fix UAF in __blkcg_rstat_flush()
When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries.
Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.(CVE-2026-63802)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close
Since hci_dev_close_sync() can now be called during the reset path, we should also set HCI_CMD_DRAIN_WORKQUEUE. This avoids queuing timeouts while the hdev workqueue is being drained.(CVE-2026-63974)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp
If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2cap_chan_del may invalidate the tmp cursor created by list_for_each_entry_safe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected.
Calling l2cap_chan_clone directly may still lead to l2cap_chan_del so instead schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously.(CVE-2026-63975)
In the Linux kernel, the following vulnerability has been resolved:
irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT
On PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via run_irq_workd(), so irq_work_sync() uses rcuwait() to wait for BUSY==0.
After irq_work_single() clears BUSY via atomic_cmpxchg(), it still dereferences @work for irq_work_is_hard() and rcuwait_wake_up().
An irq_work_sync() caller on another CPU that enters after BUSY is cleared can observe BUSY==0 immediately, return, and free the work before those accesses complete — causing a use-after-free.
Fix this by wrapping run_irq_workd() in guard(rcu)() so that the entire irq_work_single() execution is within an RCU read-side critical section. Then add synchronize_rcu() in irq_work_sync() after rcuwait_wait_event() to ensure the caller waits for the RCU grace period before returning, preventing premature frees.(CVE-2026-64073)
In the Linux kernel, the following vulnerability has been resolved:
rbd: eliminate a race in lock_dwork draining on unmap
Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are written, lock_dwork may be (re)queued more than it's actually needed: for example in case a new I/O request comes in while we are in the middle of rbd_acquire_lock() on behalf of another I/O request. This is expected and with rbd_release_lock() preemptively canceling lock_dwork is benign under normal operation.
A more problematic example is maybe_kick_acquire():
if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {
dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev);
mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0);
}
It's not unrealistic for lock_dwork to get canceled right after delayed_work_pending() returns true and for mod_delayed_work() to requeue it right there anyway. This is a classic TOCTOU race.
When it comes to unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbd_dev_image_unlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lock_dwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lock_dwork is canceled only in cancel_tasks_sync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybe_kick_acquire(). This may result in rbd_acquire_lock() executing after rbd_dev_device_release() and rbd_dev_image_release() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated
rbd_assert(rbd_image_format_valid(rbd_dev->image_format));
in rbd_dev_header_info() which is called via rbd_dev_refresh() from rbd_post_acquire_action().
Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbd_dev_image_unlock().(CVE-2026-64112)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"perf-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.1.20.157.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.1.20.157.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"perf-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.1.20.157.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-145.1.20.157.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band()\n\nSimplify the code by using device managed memory allocations.\n\nThis also fixes a memory leak in rtw_register_hw(). The supported bands\nwere not freed in the error path.\n\nCopied from commit 145df52a8671 (\u0026quot;wifi: rtw89: Convert\nrtw89_core_set_supported_band to use devm_*\u0026quot;).(CVE-2025-71273)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: hold dev ref until after transport_finish NF_HOOK\n\nAfter async crypto completes, xfrm_input_resume() calls dev_put()\nimmediately on re-entry before the skb reaches transport_finish.\nThe skb-\u0026gt;dev pointer is then used inside NF_HOOK and its okfn,\nwhich can race with device teardown.\n\nRemove the dev_put from the async resumption entry and instead\ndrop the reference after the NF_HOOK call in transport_finish,\nusing a saved device pointer since NF_HOOK may consume the skb.\nThis covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip\nthe okfn.\n\nFor non-transport exits (decaps, gro, drop) and secondary\nasync return points, release the reference inline when\nasync is set.(CVE-2026-31663)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86: shadow stacks: proper error handling for mmap lock\n\n\uae40\uc601\ubbfc reports that shstk_pop_sigframe() doesn\u0026apos;t check for errors from\nmmap_read_lock_killable(), which is a silly oversight, and also shows\nthat we haven\u0026apos;t marked those functions with \u0026quot;__must_check\u0026quot;, which would\nhave immediately caught it.\n\nSo let\u0026apos;s fix both issues.(CVE-2026-43109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsrcu: Use irq_work to start GP in tiny SRCU\n\nTiny SRCU\u0026apos;s srcu_gp_start_if_needed() directly calls schedule_work(),\nwhich acquires the workqueue pool-\u0026gt;lock.\n\nThis causes a lockdep splat when call_srcu() is called with a scheduler\nlock held, due to:\n\n call_srcu() [holding pi_lock]\n srcu_gp_start_if_needed()\n schedule_work() -\u0026gt; pool-\u0026gt;lock\n\n workqueue_init() / create_worker() [holding pool-\u0026gt;lock]\n wake_up_process() -\u0026gt; try_to_wake_up() -\u0026gt; pi_lock\n\nAlso add irq_work_sync() to cleanup_srcu_struct() to prevent a\nuse-after-free if a queued irq_work fires after cleanup begins.\n\nTested with rcutorture SRCU-T and no lockdep warnings.\n\n[ Thanks to Boqun for similar fix in patch \u0026quot;rcu: Use an intermediate irq_work\nto start process_srcu()\u0026quot; ](CVE-2026-43115)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: fix 22000 series SMEM parsing\n\nIf the firmware were to report three LMACs (which doesn\u0026apos;t\nexist in hardware) then using \u0026quot;fwrt-\u0026gt;smem_cfg.lmac[2]\u0026quot; is\nan overrun of the array. Reject such and use IWL_FW_CHECK\ninstead of WARN_ON in this function.(CVE-2026-43172)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbonding: fix type confusion in bond_setup_by_slave()\n\nkernel BUG at net/core/skbuff.c:2306!\nOops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\nRIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306\nRSP: 0018:ffffc90004aff760 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e\nRDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900\nRBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000\nR10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780\nR13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900\n dev_hard_header include/linux/netdevice.h:3439 [inline]\n packet_snd net/packet/af_packet.c:3028 [inline]\n packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg net/socket.c:742 [inline]\n ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592\n ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646\n __sys_sendmsg+0x170/0x220 net/socket.c:2678\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fe1a0e6c1a9\n\nWhen a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond,\nbond_setup_by_slave() directly copies the slave\u0026apos;s header_ops to the\nbond device:\n\n bond_dev-\u0026gt;header_ops = slave_dev-\u0026gt;header_ops;\n\nThis causes a type confusion when dev_hard_header() is later called\non the bond device. Functions like ipgre_header(), ip6gre_header(),all use\nnetdev_priv(dev) to access their device-specific private data. When\ncalled with the bond device, netdev_priv() returns the bond\u0026apos;s private\ndata (struct bonding) instead of the expected type (e.g. struct\nip_tunnel), leading to garbage values being read and kernel crashes.\n\nFix this by introducing bond_header_ops with wrapper functions that\ndelegate to the active slave\u0026apos;s header_ops using the slave\u0026apos;s own\ndevice. This ensures netdev_priv() in the slave\u0026apos;s header functions\nalways receives the correct device.\n\nThe fix is placed in the bonding driver rather than individual device\ndrivers, as the root cause is bond blindly inheriting header_ops from\nthe slave without considering that these callbacks expect a specific\nnetdev_priv() layout.\n\nThe type confusion can be observed by adding a printk in\nipgre_header() and running the following commands:\n\n ip link add dummy0 type dummy\n ip addr add 10.0.0.1/24 dev dummy0\n ip link set dummy0 up\n ip link add gre1 type gre local 10.0.0.1\n ip link add bond1 type bond mode active-backup\n ip link set gre1 master bond1\n ip link set gre1 up\n ip link set bond1 up\n ip addr add fe80::1/64 dev bond1(CVE-2026-43456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-scsi: avoid Non-NCQ command starvation\n\nWhen a non-NCQ command is issued while NCQ commands are being executed,\nata_scsi_qc_issue() indicates to the SCSI layer that the command issuing\nshould be deferred by returning SCSI_MLQUEUE_XXX_BUSY. This command\ndeferring is correct and as mandated by the ACS specifications since\nNCQ and non-NCQ commands cannot be mixed.\n\nHowever, in the case of a host adapter using multiple submission queues,\nwhen the target device is under a constant load of NCQ commands, there\nare no guarantees that requeueing the non-NCQ command will be executed\nlater and it may be deferred again repeatedly as other submission queues\ncan constantly issue NCQ commands from different CPUs ahead of the\nnon-NCQ command. This can lead to very long delays for the execution of\nnon-NCQ commands, and even complete starvation for these commands in the\nworst case scenario.\n\nSince the block layer and the SCSI layer do not distinguish between\nqueueable (NCQ) and non queueable (non-NCQ) commands, libata-scsi SAT\nimplementation must ensure forward progress for non-NCQ commands in the\npresence of NCQ command traffic. This is similar to what SAS HBAs with a\nhardware/firmware based SAT implementation do.\n\nImplement such forward progress guarantee by limiting requeueing of\nnon-NCQ commands from ata_scsi_qc_issue(): when a non-NCQ command is\nreceived and NCQ commands are in-flight, do not force a requeue of the\nnon-NCQ command by returning SCSI_MLQUEUE_XXX_BUSY and instead return 0\nto indicate that the command was accepted but hold on to the qc using\nthe new deferred_qc field of struct ata_port.\n\nThis deferred qc will be issued using the work item deferred_qc_work\nrunning the function ata_scsi_deferred_qc_work() once all in-flight\ncommands complete, which is checked with the port qc_defer() callback\nreturn value indicating that no further delay is necessary. This check\nis done using the helper function ata_scsi_schedule_deferred_qc() which\nis called from ata_scsi_qc_complete(). This thus excludes this mechanism\nfrom all internal non-NCQ commands issued by ATA EH.\n\nWhen a port deferred_qc is non NULL, that is, the port has a command\nwaiting for the device queue to drain, the issuing of all incoming\ncommands (both NCQ and non-NCQ) is deferred using the regular busy\nmechanism. This simplifies the code and also avoids potential denial of\nservice problems if a user issues too many non-NCQ commands.\n\nFinally, whenever ata EH is scheduled, regardless of the reason, a\ndeferred qc is always requeued so that it can be retried once EH\ncompletes. This is done by calling the function\nata_scsi_requeue_deferred_qc() from ata_eh_set_pending(). This avoids\nthe need for any special processing for the deferred qc in case of NCQ\nerror, link or device reset, or device timeout.(CVE-2026-45855)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: drop extent cache when splitting extent fails\n\nWhen the split extent fails, we might leave some extents still being\nprocessed and return an error directly, which will result in stale\nextent entries remaining in the extent status tree. So drop all of the\nremaining potentially stale extents if the splitting fails.(CVE-2026-45899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nselinux: fix overlayfs mmap() and mprotect() access checks\n\nThe existing SELinux security model for overlayfs is to allow access if\nthe current task is able to access the top level file (the \u0026quot;user\u0026quot; file)\nand the mounter\u0026apos;s credentials are sufficient to access the lower\nlevel file (the \u0026quot;backing\u0026quot; file). Unfortunately, the current code does\nnot properly enforce these access controls for both mmap() and mprotect()\noperations on overlayfs filesystems.\n\nThis patch makes use of the newly created security_mmap_backing_file()\nLSM hook to provide the missing backing file enforcement for mmap()\noperations, and leverages the backing file API and new LSM blob to\nprovide the necessary information to properly enforce the mprotect()\naccess controls.(CVE-2026-46054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: ADD_ADDR rtx: always decrease sk refcount\n\nWhen an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer().\nIt should then be released in all cases at the end.\n\nSome (unlikely) checks were returning directly instead of calling\nsock_put() to decrease the refcount. Jump to a new \u0026apos;exit\u0026apos; label to call\n__sock_put() (which will become sock_put() in the next commit) to fix\nthis potential leak.\n\nWhile at it, drop the \u0026apos;!msk\u0026apos; check which cannot happen because it is\nnever reset, and explicitly mark the remaining one as \u0026quot;unlikely\u0026quot;.(CVE-2026-46158)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nselinux: allow multiple opens of /sys/fs/selinux/policy\n\nCurrently there can only be a single open of /sys/fs/selinux/policy at\nany time. This allows any process to block any other process from\nreading the kernel policy. The original motivation seems to have been\na mix of preventing an inconsistent view of the policy size and\npreventing userspace from allocating kernel memory without bound, but\nthis is arguably equally bad. Eliminate the policy_opened flag and\nshrink the critical section that the policy mutex is held. While we\nare making changes here, drop a couple of extraneous BUG_ONs.(CVE-2026-46302)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6_vti: set netns_immutable on the fallback device.\n\njohn1988 and Noam Rathaus reported that vti6_init_net() does not set the\nnetns_immutable flag on the per-netns fallback tunnel device (ip6_vti0).\n\nOther similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel)\ncorrectly set this flag during their fallback device initialization to\nprevent them from being moved to another network namespace.(CVE-2026-52909)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: skbuff: fix missing zerocopy reference in pskb_carve helpers\n\npskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy\nthe old skb_shared_info header into a new buffer via memcpy(), which\nincludes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs.\nNeither function calls net_zcopy_get() for the new shinfo, creating an\nunaccounted holder: every skb_shared_info with destructor_arg set will\ncall skb_zcopy_clear() once when freed, but the corresponding\nnet_zcopy_get() was never called for the new copy. Repeated calls\ndrive uarg-\u0026gt;refcnt to zero prematurely, freeing ubuf_info_msgzc while\nTX skbs still hold live destructor_arg pointers.\n\nKASAN reports use-after-free on a freed ubuf_info_msgzc:\n\n BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810\n Read of size 8 at addr ffff88801574d3e8 by task poc/220\n\n Call Trace:\n skb_release_data+0x77b/0x810\n kfree_skb_list_reason+0x13e/0x610\n skb_release_data+0x4cd/0x810\n sk_skb_reason_drop+0xf3/0x340\n skb_queue_purge_reason+0x282/0x440\n rds_tcp_inc_free+0x1e/0x30\n rds_recvmsg+0x354/0x1780\n __sys_recvmsg+0xdf/0x180\n\n Allocated by task 219:\n msg_zerocopy_realloc+0x157/0x7b0\n tcp_sendmsg_locked+0x2892/0x3ba0\n\n Freed by task 219:\n ip_recv_error+0x74a/0xb10\n tcp_recvmsg+0x475/0x530\n\nThe skb consuming the late access still referenced the same uarg via\nshinfo-\u0026gt;destructor_arg copied by pskb_carve_inside_nonlinear() without\na refcount bump. This has been verified to be reliably exploitable: a\nworking proof-of-concept achieves full root privilege escalation from\nan unprivileged local user on a default kernel configuration.\n\nThe fix follows the pattern of pskb_expand_head() which has the same\nmemcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get()\nis placed after skb_orphan_frags() succeeds, so the orphan error path\nneeds no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is\nplaced after all failure points and just before skb_release_data(), so\nno error path needs cleanup at all -- matching pskb_expand_head() more\nclosely and avoiding the need for a balancing net_zcopy_put().(CVE-2026-52943)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling\n\nA SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in\nsend_sigio() and send_sigurg() when a process group receives a signal.\n\nWhen FASYNC is configured for a process group (PIDTYPE_PGID), both\nfunctions use read_lock(\u0026amp;tasklist_lock) to traverse the task list.\nHowever, they are frequently called from softirq context:\n- send_sigio() via input_inject_event -\u0026gt; kill_fasync\n- send_sigurg() via tcp_check_urg -\u0026gt; sk_send_sigurg (NET_RX_SOFTIRQ)\n\nThe deadlock is caused by the rwlock writer fairness mechanism:\n1. CPU 0 (process context) holds read_lock(\u0026amp;tasklist_lock) in do_wait().\n2. CPU 1 (process context) attempts write_lock(\u0026amp;tasklist_lock) in\n fork() or exit() and spins, which blocks all new readers.\n3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).\n4. The softirq calls send_sigurg() and attempts to acquire\n read_lock(\u0026amp;tasklist_lock), deadlocking because CPU 1 is waiting.\n\nSince PID hashing and do_each_pid_task() traversals are already\nRCU-protected, the read_lock on tasklist_lock is no longer strictly\nrequired for safe traversal. Fix this by replacing tasklist_lock with\nrcu_read_lock(), aligning the process group signaling path with the\nsingle-PID path. This also mitigates a potential remote denial of\nservice vector via TCP URG packets.\n\nLockdep splat:\n=====================================================\nWARNING: SOFTIRQ-safe -\u0026gt; SOFTIRQ-unsafe lock order detected\n[...]\nChain exists of:\n \u0026amp;dev-\u0026gt;event_lock --\u0026gt; \u0026amp;f_owner-\u0026gt;lock --\u0026gt; tasklist_lock\n\nPossible interrupt unsafe locking scenario:\n CPU0 CPU1\n ---- ----\n lock(tasklist_lock);\n local_irq_disable();\n lock(\u0026amp;dev-\u0026gt;event_lock);\n lock(\u0026amp;f_owner-\u0026gt;lock);\n \u0026lt;Interrupt\u0026gt;\n lock(\u0026amp;dev-\u0026gt;event_lock);\n\n*** DEADLOCK ***(CVE-2026-52946)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb/client: fix possible infinite loop and oob read in symlink_data()\n\nOn 32-bit architectures, the infinite loop is as follows:\n\n len = p-\u0026gt;ErrorDataLength == 0xfffffff8\n u8 *next = p-\u0026gt;ErrorContextData + len\n next == p\n\nOn 32-bit architectures, the out-of-bounds read is as follows:\n\n len = p-\u0026gt;ErrorDataLength == 0xfffffff0\n u8 *next = p-\u0026gt;ErrorContextData + len\n next == (u8 *)p - 8(CVE-2026-52967)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: join hook list via splice_list_rcu() in commit phase\n\nPublish new hooks in the list into the basechain/flowtable using\nsplice_list_rcu() to ensure netlink dump list traversal via rcu is safe\nwhile concurrent ruleset update is going on.(CVE-2026-52988)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/psi: fix race between file release and pressure write\n\nA potential race condition exists between pressure write and cgroup file\nrelease regarding the priv member of struct kernfs_open_file, which\ntriggers the uaf reported in [1].\n\nConsider the following scenario involving execution on two separate CPUs:\n\n CPU0\t\t\t\t\tCPU1\n ====\t\t\t\t\t====\n\t\t\t\t\tvfs_rmdir()\n\t\t\t\t\tkernfs_iop_rmdir()\n\t\t\t\t\tcgroup_rmdir()\n\t\t\t\t\tcgroup_kn_lock_live()\n\t\t\t\t\tcgroup_destroy_locked()\n\t\t\t\t\tcgroup_addrm_files()\n\t\t\t\t\tcgroup_rm_file()\n\t\t\t\t\tkernfs_remove_by_name()\n\t\t\t\t\tkernfs_remove_by_name_ns()\n vfs_write()\t\t\t\t__kernfs_remove()\n new_sync_write()\t\t\tkernfs_drain()\n kernfs_fop_write_iter()\t\tkernfs_drain_open_files()\n cgroup_file_write()\t\t\tkernfs_release_file()\n pressure_write()\t\t\tcgroup_file_release()\n ctx = of-\u0026gt;priv;\n\t\t\t\t\tkfree(ctx);\n \t\t\t\t\tof-\u0026gt;priv = NULL;\n\t\t\t\t\tcgroup_kn_unlock()\n cgroup_kn_lock_live()\n cgroup_get(cgrp)\n cgroup_kn_unlock()\n if (ctx-\u0026gt;psi.trigger) // here, trigger uaf for ctx, that is of-\u0026gt;priv\n\nThe cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards\nthe memory deallocation of of-\u0026gt;priv performed within cgroup_file_release().\nHowever, the operations involving of-\u0026gt;priv executed within pressure_write()\nare not entirely covered by the protection of cgroup_mutex. Consequently,\nif the code in pressure_write(), specifically the section handling the\nctx variable executes after cgroup_file_release() has completed, a uaf\nvulnerability involving of-\u0026gt;priv is triggered.\n\nTherefore, the issue can be resolved by extending the scope of the\ncgroup_mutex lock within pressure_write() to encompass all code paths\ninvolving of-\u0026gt;priv, thereby properly synchronizing the race condition\noccurring between cgroup_file_release() and pressure_write().\n\nAnd, if an live kn lock can be successfully acquired while executing\nthe pressure write operation, it indicates that the cgroup deletion\nprocess has not yet reached its final stage; consequently, the priv\npointer within open_file cannot be NULL. Therefore, the operation to\nretrieve the ctx value must be moved to a point *after* the live kn\nlock has been successfully acquired.\n\nIn another situation, specifically after entering cgroup_kn_lock_live()\nbut before acquiring cgroup_mutex, there exists a different class of\nrace condition:\n\nCPU0: write memory.pressure CPU1: write cgroup.pressure=0\n===========================\t\t =============================\n\nkernfs_fop_write_iter()\n kernfs_get_active_of(of)\n pressure_write()\n cgroup_kn_lock_live(memory.pressure)\n cgroup_tryget(cgrp)\n kernfs_break_active_protection(kn)\n ... blocks on cgroup_mutex\n\n \t cgroup_pressure_write()\n \t cgroup_kn_lock_live(cgroup.pressure)\n \t cgroup_file_show(memory.pressure, false)\n \t kernfs_show(false)\n \t kernfs_drain_open_files()\n \t cgroup_file_release(of)\n \t kfree(ctx)\n \t of-\u0026gt;priv = NULL\n \t cgroup_kn_unlock()\n\n ... acquires cgroup_mutex\n ctx = of-\u0026gt;priv; // may now be NULL\n if (ctx-\u0026gt;psi.trigger) // NULL dereference\n\nConsequently, there is a possibility that of-\u0026gt;priv is NULL, the pressure\nwrite needs to check for this.\n\nNow that the scope of the cgroup_mutex has been expanded, the original\nexplicit cgroup_get/put operations are no longer necessary, this is\nbecause acquiring/releasing the live kn lock inherently executes a\ncgroup get/put operation.\n\n[1]\nBUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011\nCall Trace:\n pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011\n cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43\n---truncated---(CVE-2026-52991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nat: use kfree_rcu to release ops\n\nFlorian Westphal says:\n\n\u0026quot;Historically this is not an issue, even for normal base hooks: the data\npath doesn\u0026apos;t use the original nf_hook_ops that are used to register the\ncallbacks.\n\nHowever, in v5.14 I added the ability to dump the active netfilter\nhooks from userspace.\n\nThis code will peek back into the nf_hook_ops that are available\nat the tail of the pointer-array blob used by the datapath.\n\nThe nat hooks are special, because they are called indirectly from\nthe central nat dispatcher hook. They are currently invisible to\nthe nfnl hook dump subsystem though.\n\nBut once that changes the nat ops structures have to be deferred too.\u0026quot;\n\nUpdate nf_nat_register_fn() to deal with partial exposition of the hooks\nfrom error path which can be also an issue for nfnetlink_hook.(CVE-2026-53000)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npppoe: drop PFC frames\n\nRFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT\nRECOMMENDED for PPPoE. In practice, pppd does not support negotiating\nPFC for PPPoE sessions, and the current PPPoE driver assumes an\nuncompressed (2-byte) protocol field. However, the generic PPP layer\nfunction ppp_input() is not aware of the negotiation result, and still\naccepts PFC frames.\n\nIf a peer with a broken implementation or an attacker sends a frame with\na compressed (1-byte) protocol field, the subsequent PPP payload is\nshifted by one byte. This causes the network header to be 4-byte\nmisaligned, which may trigger unaligned access exceptions on some\narchitectures.\n\nTo reduce the attack surface, drop PPPoE PFC frames. Introduce\nppp_skb_is_compressed_proto() helper function to be used in both\nppp_generic.c and pppoe.c to avoid open-coding.(CVE-2026-53003)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp\n\nl2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding\nl2cap_chan_lock(). Every other l2cap_chan_del() caller in the file\nacquires the lock first. A remote BLE device can send a crafted\nL2CAP ECRED reconfiguration response to corrupt the channel list\nwhile another thread is iterating it.\n\nAdd l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(),\nand l2cap_chan_unlock() and l2cap_chan_put() after, matching the\npattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().(CVE-2026-53071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER\n\nWhen protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls\nhci_connect_cfm(conn) without hdev-\u0026gt;lock. Generally hci_connect_cfm()\nassumes it is held, and if conn is deleted concurrently -\u0026gt; UAF.\n\nOnly SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen,\nand HCI_EV_CONN_REQUEST is not generated for ISO. In the non-deferred\nlistening socket code paths, hci_connect_cfm(conn) is called with\nhdev-\u0026gt;lock held.\n\nFix by holding the lock.(CVE-2026-53072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix ld_{abs,ind} failure path analysis in subprogs\n\nUsage of ld_{abs,ind} instructions got extended into subprogs some time\nago via commit 09b28d76eac4 (\u0026quot;bpf: Add abnormal return checks.\u0026quot;). These\nare only allowed in subprograms when the latter are BTF annotated and\nhave scalar return types.\n\nThe code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 +\nexit) from legacy cBPF times. While the enforcement is on scalar return\ntypes, the verifier must also simulate the path of abnormal exit if the\npacket data load via ld_{abs,ind} failed.\n\nThis is currently not the case. Fix it by having the verifier simulate\nboth success and failure paths, and extend it in similar ways as we do\nfor tail calls. The success path (r0=unknown, continue to next insn) is\npushed onto stack for later validation and the r0=0 and return to the\ncaller is done on the fall-through side.(CVE-2026-53090)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: wake raid456 reshape waiters before suspend\n\nDuring raid456 reshape, direct IO across the reshape position can sleep\nin raid5_make_request() waiting for reshape progress while still\nholding an active_io reference. If userspace then freezes reshape and\nwrites md/suspend_lo or md/suspend_hi, mddev_suspend() kills active_io\nand waits for all in-flight IO to drain.\n\nThis can deadlock: the IO needs reshape progress to continue, but the\nreshape thread is already frozen, so the active_io reference is never\ndropped and suspend never completes.\n\nraid5_prepare_suspend() already wakes wait_for_reshape for dm-raid. Do\nthe same for normal md suspend when reshape is already interrupted, so\nwaiting raid456 IO can abort, drop its reference, and let suspend\nfinish.\n\nThe mdadm test tests/25raid456-reshape-deadlock reproduces the hang.(CVE-2026-53123)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: require Ethernet MAC header before using eth_hdr()\n\n`ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and\n`hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)`\nafter either assuming that the skb is associated with an Ethernet\ndevice or checking only that the `ETH_HLEN` bytes at\n`skb_mac_header(skb)` lie between `skb-\u0026gt;head` and `skb-\u0026gt;data`.\n\nMake these paths first verify that the skb is associated with an\nEthernet device, that the MAC header was set, and that it spans at\nleast a full Ethernet header before accessing `eth_hdr(skb)`.(CVE-2026-53131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: fix potential unbounded skb queue\n\nvirtio_transport_inc_rx_pkt() checks vvs-\u0026gt;rx_bytes + len \u0026gt; vvs-\u0026gt;buf_alloc.\n\nvirtio_transport_recv_enqueue() skips coalescing for packets\nwith VIRTIO_VSOCK_SEQ_EOM.\n\nIf fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,\na very large number of packets can be queued\nbecause vvs-\u0026gt;rx_bytes stays at 0.\n\nFix this by estimating the skb metadata size:\n\n\t(Number of skbs in the queue) * SKB_TRUESIZE(0)(CVE-2026-53132)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_fib: fix stale stack leak via the OIFNAME register\n\nFor NFT_FIB_RESULT_OIFNAME the destination register is declared with\nlen = IFNAMSIZ (four 32-bit registers), but on the lookup-fail,\nRTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one\nregister via \u0026quot;*dest = 0\u0026quot;. The remaining three registers are left as\nwhatever was on the stack in nft_do_chain()\u0026apos;s struct nft_regs, and a\ndownstream expression that loads the register span can leak that\nuninitialised kernel stack to userspace.\n\nThe NFTA_FIB_F_PRESENT existence check has the same shape: it is only\nmeaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type\nwhile the eval stores a single byte via nft_reg_store8(), leaving the rest\nof the declared span stale.\n\nFix both:\n\n - replace the bare \u0026quot;*dest = 0\u0026quot; in the eval with nft_fib_store_result(),\n which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already\n used on the other early-return path), and\n\n - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its\n destination as a single u8, so the marked span matches the one byte\n the eval writes.(CVE-2026-53134)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Clamp VBIOS HDMI retimer register count to array size\n\n[Why \u0026amp; How]\nThe VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and\nHdmi6GRegNum fields that are used as loop bounds when copying retimer I2C\nregister settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9]\nand dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated\nbefore use, so a malformed VBIOS can specify values up to 255, causing an\nout-of-bounds heap write during driver probe.\n\nClamp each register count to the destination array size using min_t()\nbefore the copy loops, in both get_integrated_info_v11() and\nget_integrated_info_v2_1().\n\n(cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)(CVE-2026-53136)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size\n\n[Why \u0026amp; How]\nDuring HDCP 2.x repeater authentication over HDMI, the driver reads the\nsink\u0026apos;s RxStatus register and extracts a 10-bit message size field (max\nvalue 1023). This value is used as the read length for the ReceiverID\nlist without being clamped to the size of the destination buffer\nrx_id_list[177]. A malicious HDMI repeater could advertise a message\nsize larger than the buffer, causing an out-of-bounds write during the\nI2C read.\n\nClamp the read length in mod_hdcp_read_rx_id_list() to the size of the\nrx_id_list buffer, matching the approach already used in the DP branch.\n\n(cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)(CVE-2026-53137)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: Bound root directory content to block size\n\n__tb_property_parse_dir() does not check that content_offset +\ncontent_len fits within block_len for the root directory case.\nWhen rootdir-\u0026gt;length equals or exceeds block_len - 2, the entry\nloop reads past the allocated property block.\n\nAdd a bounds check after computing content_offset and content_len\nto reject directories whose content extends past the block.(CVE-2026-53149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ninet: frags: fix use-after-free caused by the fqdir_pre_exit() flush\n\nOn netns teardown, fqdir_pre_exit() walks the fqdir rhashtable and\nflushes every fragment queue that is not yet complete using\ninet_frag_queue_flush(). That helper frees all the skbs queued on the\nfragment queue but does not set INET_FRAG_COMPLETE, and leaves\nq-\u0026gt;fragments_tail and q-\u0026gt;last_run_head pointing at the freed skbs.\nThe queue itself stays in the rhashtable.\n\nfqdir_pre_exit() first lowers high_thresh to 0 to stop new queue lookups,\nbut it cannot stop a fragment that already obtained the queue through\ninet_frag_find() earlier and stalled just before taking the queue lock.\nOnce that fragment resumes after the flush and takes the queue lock,\nit passes the INET_FRAG_COMPLETE check and then dereferences the freed\nfragments_tail. inet_frag_queue_insert() reads FRAG_CB() and -\u0026gt;len of\nthat pointer and, on the append path, writes -\u0026gt;next_frag, causing a\nslab use-after-free. IPv6, nf_conntrack_reasm6 and 6lowpan reassembly\nshare the same flush path and are affected as well.\n\nReset rb_fragments, fragments_tail and last_run_head in\ninet_frag_queue_flush() so a flushed queue no longer points at the\nfreed skbs. A fragment that resumes after the flush and takes the\nqueue lock then finds an empty queue and starts a new run instead of\ndereferencing the freed fragments_tail. ip_frag_reinit() already\nperformed this reset after its own flush, so drop the now duplicate\ncode there.(CVE-2026-53175)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN\n\nIn drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done()\ncomputes the login request payload length as wc-\u0026gt;byte_len minus\nISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int.\nA remote iSER initiator can post a login Send work request carrying\nfewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows\nand login_req_len becomes negative.\n\nisert_rx_login_req() then reads that negative length back into a signed\nint, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the\nmin() is signed it keeps the negative value; the value is then passed as\nthe memcpy() length and sign-extended to a multi-gigabyte size_t. The\ncopy into the 8192-byte login-\u0026gt;req_buf runs far out of bounds and\nfaults, crashing the target node. The login phase precedes iSCSI\nauthentication, so no credentials are required to reach this path.\n\nReject any login PDU shorter than ISER_HEADERS_LEN before the\nsubtraction, mirroring the existing early return on a failed work\ncompletion, so login_req_len can never go negative. The upper bound was\nalready safe: a posted login buffer cannot deliver more than\nISER_RX_PAYLOAD_SIZE, so the difference stays at or below\nMAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing\nlower bound needs to be added.(CVE-2026-53176)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix NULL pointer dereference\n\nPCIe errors detected by a Root Port or Downstream Port cause error\nrecovery services to run on all subordinate devices regardless of\nadministrative state.\n\nThe .error_detected() callback, bnxt_io_error_detected(), disables\nand synchronizes IRQs via bnxt_disable_int_sync(), which calls\nbnxt_cp_num_to_irq_num() to map completion rings to IRQs using\nbp-\u0026gt;bnapi.\n\nSince bp-\u0026gt;bnapi is allocated on NIC open and freed on NIC close, PCIe\nerror recovery on a closed NIC can dereference a NULL pointer.\n\nCheck if bp-\u0026gt;bnapi is NULL before disabling and synchronizing IRQs.(CVE-2026-53177)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp: clear skb-\u0026gt;dev before running a sockmap verdict\n\nOn the UDP receive path skb-\u0026gt;dev is repurposed as dev_scratch (the\ntruesize/state cache set by udp_set_dev_scratch()), through the\nunion { struct net_device *dev; unsigned long dev_scratch; } in sk_buff.\n\nWhen a UDP socket is in a sockmap, sk_data_ready is\nsk_psock_verdict_data_ready(), which calls udp_read_skb() -\u0026gt; recv_actor()\n(sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq.\nIf that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp,\nbpf_skc_lookup_tcp), bpf_skc_lookup() does:\n\n\tif (skb-\u0026gt;dev)\n\t\tcaller_net = dev_net(skb-\u0026gt;dev);\n\nskb-\u0026gt;dev still holds the dev_scratch value (a non-NULL integer), so dev_net()\ndereferences it as a struct net_device * and the kernel takes a general\nprotection fault on a non-canonical address in softirq:\n\n Oops: general protection fault, probably for non-canonical address 0x1010000800004a0\n CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full)\n RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline]\n RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n bpf_prog_4675cb904b7071f8+0x12e/0x14e\n bpf_prog_run_pin_on_cpu+0xc6/0x1f0\n sk_psock_verdict_recv+0x1ba/0x350\n udp_read_skb+0x31a/0x370\n sk_psock_verdict_data_ready+0x2e3/0x600\n __udp_enqueue_schedule_skb+0x4c8/0x650\n udpv6_queue_rcv_one_skb+0x3ec/0x740\n udp6_unicast_rcv_skb+0x11d/0x140\n ip6_protocol_deliver_rcu+0x61e/0x950\n ip6_input_finish+0xa9/0x150\n NF_HOOK+0x286/0x2f0\n ip6_input+0x117/0x220\n NF_HOOK+0x286/0x2f0\n __netif_receive_skb+0x85/0x200\n process_backlog+0x374/0x9a0\n __napi_poll+0x4f/0x1c0\n net_rx_action+0x3b0/0x770\n handle_softirqs+0x15a/0x460\n do_softirq+0x57/0x80\n \u0026lt;/IRQ\u0026gt;\n\nThe rmem charge that dev_scratch accounted for is released by skb_recv_udp() on\ndequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear\nskb-\u0026gt;dev so bpf_skc_lookup() falls back to sock_net(skb-\u0026gt;sk), which\nskb_set_owner_sk_safe() set just above.(CVE-2026-53184)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/srp: bound SRP_RSP sense copy by the received length\n\nsrp_process_rsp() copies sense data from rsp-\u0026gt;data + resp_data_len,\nwhere resp_data_len is the full 32-bit value supplied by the SRP target\nand is never checked against the number of bytes actually received\n(wc-\u0026gt;byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so\nat most 96 bytes are copied, but the source offset is not bounded.\n\nA malicious or compromised SRP target on the InfiniBand/RoCE fabric that\nthe initiator has logged into can return an SRP_RSP with\nSRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer\nis allocated at the target-chosen max_ti_iu_len, so the source of the\nsense copy lands past the bytes actually received; with resp_data_len\nnear 0xFFFFFFFF it is gigabytes past the buffer and the read faults.\n\nCopy the sense data only if it has not been truncated, that is, only if\nthe response header, the response data, and the sense region fit within\nthe bytes actually received; otherwise drop the sense and log. The\nin-tree iSER and NVMe-RDMA receive paths already bound their parse by\nwc-\u0026gt;byte_len; this brings ib_srp into line with them.(CVE-2026-53186)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait()\n\ndma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first()\nwhich does cursor-\u0026gt;chain = dma_fence_get(head), taking an extra\nreference. On normal loop completion, dma_fence_unwrap_next()\nreleases this via dma_fence_chain_walk() -\u0026gt; dma_fence_put().\n\nWhen virtio_gpu_do_fence_wait() fails and the function returns early\nfrom inside the loop, the cursor-\u0026gt;chain reference is never released.\nThis is the only caller in the entire kernel that does an early return\ninside dma_fence_unwrap_for_each.\n\nAdd dma_fence_put(itr.chain) before the early return.(CVE-2026-53190)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison\n\nTwo concurrent madvise(MADV_HWPOISON) calls on the same hugetlb page can\ntrigger a recursive spinlock self-deadlock (AA deadlock) on hugetlb_lock\nwhen racing with a concurrent unmap:\n\n thread#0 thread#1\n -------- --------\n madvise(folio, MADV_HWPOISON)\n -\u0026gt; poisons the folio successfully\n madvise(folio, MADV_HWPOISON) unmap(folio)\n try_memory_failure_hugetlb\n get_huge_page_for_hwpoison\n spin_lock_irq(\u0026amp;hugetlb_lock) \u0026lt;- held\n __get_huge_page_for_hwpoison\n hugetlb_update_hwpoison()\n -\u0026gt; MF_HUGETLB_FOLIO_PRE_POISONED\n goto out:\n folio_put()\n refcount: 1 -\u0026gt; 0\n free_huge_folio()\n spin_lock_irqsave(\u0026amp;hugetlb_lock)\n -\u0026gt; AA DEADLOCK!\n\nThe out: path in __get_huge_page_for_hwpoison() calls folio_put() to drop\nthe GUP reference while the hugetlb_lock is still held by the hugetlb.c\nwrapper get_huge_page_for_hwpoison(). If concurrent unmap has released\nthe page table mapping reference, folio_put() drops the folio refcount to\nzero, triggering free_huge_folio() which attempts to re-acquire the\nnon-recursive hugetlb_lock.\n\nFix this by moving hugetlb_lock acquisition from the hugetlb.c wrapper\ninto get_huge_page_for_hwpoison(). Place spin_unlock_irq() before the\nfolio_put() at the out: label so the folio is always released outside the\nlock.\n\n[(CVE-2026-53207)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_exthdr: fix register tracking for F_PRESENT flag\n\nnft_exthdr_init() passes user-controlled priv-\u0026gt;len to\nnft_parse_register_store(), which marks that many bytes in the\nregister bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT\nis set, the eval paths write only 1 byte (nft_reg_store8) or\n4 bytes (*dest = 0 on TCP/DCCP error path). When len \u0026gt; 4,\nregisters beyond the first are never written, retaining\nuninitialized stack data from nft_regs.\n\nBail out if userspace requests too much data when F_PRESENT is set.(CVE-2026-53218)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: avoid leaking percpu counter pointers\n\nThe native and compat get-entries paths copy the fixed rule entry header\nfrom the kernelized rule blob to userspace before overwriting the entry\u0026apos;s\ncounter fields with a sanitized counter snapshot.\n\nOn SMP kernels, entry-\u0026gt;counters.pcnt contains the percpu allocation\naddress used by x_tables rule counters. A caller can provide a userspace\nbuffer that faults during the initial fixed-header copy after pcnt has\nbeen copied but before the later sanitized counter copy runs. The syscall\nthen returns -EFAULT while leaving the raw percpu pointer in userspace.\n\nCopy only the fixed entry prefix before counters from the kernelized rule\nblob, then copy the sanitized counter snapshot into the counter field.\nApply this ordering to the IPv4, IPv6, and ARP native and compat\nget-entries implementations so a fault cannot expose the internal percpu\ncounter pointer.(CVE-2026-53219)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: revalidate bridge ports\n\nebt_redirect_tg() dereferences br_port_get_rcu() return without a\nNULL check, causing a kernel panic when the bridge port has been\nremoved between the original hook invocation and an NFQUEUE\nreinject.\n\nA mere NULL check isn\u0026apos;t sufficient, however. As sashiko review\npoints out userspace can not only remove the port from the bridge,\nit could also place the device in a different virtual device, e.g.\nmacvlan.\n\nIf this happens, we must drop the packet, there is no way for us to\nreinject it into the bridge path.\n\nSwitch to _upper API, we don\u0026apos;t need the bridge port structure.\nAlso, this fix keeps another bug intact:\n\nBoth nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER\ntoo aggressive, which prevents certain logging features when queueing\nin bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old\nCONFIG_BRIDGE_NETFILTER cruft is off.\n\nFixes tag is a common ancestor, this was always broken.(CVE-2026-53220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()\n\nIn vti6_tnl_lookup(), when an exact match for a tunnel fails,\nthe code falls back to searching for wildcard tunnels:\n\n- Tunnels matching the packet\u0026apos;s local address, with any remote address\n wildcard remote).\n\n- Tunnels matching the packet\u0026apos;s remote address, with any local address\n (wildcard local).\n\nHowever, vti6 stores all these different types of tunnels in the same\nhash table (ip6n-\u0026gt;tnls_r_l) prone to hash collisions.\n\nThe bug is that the fallback search loops in vti6_tnl_lookup() were\nmissing checks to ensure that the candidate tunnel actually has\na wildcard address.(CVE-2026-53221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: guard timestamp cmsgs to real error queue skbs\n\nskb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb\nfrom sk_error_queue. That assumption is not true for AF_PACKET sockets:\noutgoing packet taps are also delivered to packet sockets with\nskb-\u0026gt;pkt_type == PACKET_OUTGOING, but their skb-\u0026gt;cb is owned by AF_PACKET\ninstead of struct sock_exterr_skb.\n\nIf such an skb is received with timestamping enabled, the generic\ntimestamp cmsg path can read AF_PACKET control-buffer state as\nsock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop\ncounter overlaps opt_stats. An odd drop count makes the path emit\nSCM_TIMESTAMPING_OPT_STATS with skb-\u0026gt;len and skb-\u0026gt;data. For non-linear\nskbs this copies past the linear head and can trigger hardened usercopy or\ndisclose adjacent heap contents.\n\nKeep skb_is_err_queue() local to net/socket.c, but make it verify that\nthe PACKET_OUTGOING marker is paired with the sock_rmem_free destructor\ninstalled by sock_queue_err_skb(). AF_PACKET receive skbs use normal\nreceive ownership and no longer pass as error-queue skbs, while legitimate\nsk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free\nownership.(CVE-2026-53223)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix possible kfree_skb of ERR_PTR\n\nAfter the patch in the \u0026quot;Fixes\u0026quot; tag, the allocation of the \u0026quot;reply\u0026quot; skb\ncan happen either before or after locking the ovs_mutex.\n\nHowever, error cleanups still follow the classical reversed order,\nassuming \u0026quot;reply\u0026quot; is allocated before locking: it is freed after unlocking.\n\nIf \u0026quot;reply\u0026quot; allocation happens after locking the mutex and it fails,\n\u0026quot;reply\u0026quot; is left with an ERR_PTR, and execution jumps to the correspondent\ncleanup stage which will try to free an invalid pointer.\n\nFix this by setting the pointer to NULL after having saved its error\nvalue.(CVE-2026-53227)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: sit: reload inner IPv6 header after GSO offloads\n\nipip6_tunnel_xmit() caches the inner IPv6 header pointer at function\nentry and continues using it after iptunnel_handle_offloads().\n\nFor GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone().\nWhen the skb header is cloned, skb_header_unclone() can call\npskb_expand_head(), which may move the skb head. The pskb_expand_head()\ncontract requires pointers into the skb header to be reloaded after the\ncall.\n\nIf the later skb_realloc_headroom() branch is not taken, SIT uses the\nstale iph6 pointer to read the inner hop limit and DS field. That can\nread from a freed skb head after the old head\u0026apos;s remaining clone is\nreleased.\n\nReload iph6 after the offload helper succeeds and before subsequent\nreads from the inner IPv6 header. Keep the existing reload after\nskb_realloc_headroom(), since that branch can also replace the skb.(CVE-2026-53228)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure\n\nIn the XSK branch of mlx5e_xmit_xdp_buff(), when sq-\u0026gt;xmit_xdp_frame()\nreturns false (e.g. XDPSQ is full), the function returns without\nunmapping the DMA address or freeing the xdp_frame allocated by\nxdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on\nsuccess, so the completion path cannot recover these entries.\n\nWith CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind:\n\n DMA-API: pci 0000:08:00.0: device driver has pending DMA\n allocations while released from device [count=1116]\n One of leaked entries details: [device address=0x000000010ffd7028]\n [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy]\n WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180\n ...\n DMA-API: Mapped at:\n debug_dma_map_phys+0x4b/0xd0\n dma_map_phys+0xfd/0x2d0\n mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core]\n mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core]\n mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core]\n\nAdd the missing unmap + xdp_return_frame, matching the cleanup already\ndone in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch,\nso no per-frag unmap is needed.(CVE-2026-53229)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list\n\nmlx5_query_nic_vport_mac_list() sizes its firmware command buffer using\nthe PF\u0026apos;s log_max_current_uc/mc_list capabilities. When querying a VF\nvport with a larger configured max (via devlink), the firmware response\ncan overflow this buffer:\n\n BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core]\n Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385\n\n CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)\n Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x69/0xa0\n print_report+0x176/0x4e4\n kasan_report+0xc8/0x100\n mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core]\n esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core]\n esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core]\n esw_vport_change_handler+0x6a/0x90 [mlx5_core]\n process_one_work+0x87f/0x15e0\n worker_thread+0x62b/0x1020\n kthread+0x375/0x490\n ret_from_fork+0x4dc/0x810\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\n\nFix by querying the vport\u0026apos;s own HCA caps to size the buffer correctly.\nRefactor the function to allocate and return the MAC list internally,\nremoving the caller\u0026apos;s dependency on knowing the correct max.(CVE-2026-53230)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: restrict SO_ATTACH_FILTER to priv users\n\nThis patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets\nto users with CAP_NET_ADMIN capability.\n\nThis blocks potential side-channel attack where an unprivileged application\nattaches a filter to leak TCP sequence/acknowledgment numbers.(CVE-2026-53236)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetlabel: validate unlabeled address and mask attribute lengths\n\nnetlbl_unlabel_addrinfo_get() used the address attribute length to\ndetermine whether the attribute data could be read as an IPv4 or IPv6\naddress, but did not independently validate the corresponding mask\nattribute length. A crafted Generic Netlink request could therefore\nprovide a valid IPv4/IPv6 address attribute with a shorter mask\nattribute, which would later be read as a full struct in_addr or\nstruct in6_addr.\n\nNLA_BINARY policy lengths are maximum lengths by default, so use\nNLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask\nattributes. This rejects short attributes during policy validation and\nalso exposes the exact length requirements through policy introspection.(CVE-2026-53238)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx()\n\nFix the race by pruning the bin while still holding xfrm_policy_lock,\nbefore dropping it. Use __xfrm_policy_inexact_prune_bin() directly since\nthe lock is already held. The wrapper xfrm_policy_inexact_prune_bin()\nbecomes unused and is removed.\n\nRace:\n\n CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO)\n ========================== ==========================\n xfrm_policy_bysel_ctx():\n spin_lock_bh(xfrm_policy_lock)\n bin = xfrm_policy_inexact_lookup()\n __xfrm_policy_unlink(pol)\n spin_unlock_bh(xfrm_policy_lock)\n xfrm_policy_kill(ret)\n // wide window, lock not held\n xfrm_hash_rebuild():\n spin_lock_bh(xfrm_policy_lock)\n __xfrm_policy_inexact_flush():\n kfree_rcu(bin) // bin freed\n spin_unlock_bh(xfrm_policy_lock)\n xfrm_policy_inexact_prune_bin(bin)\n // UAF: bin is freed(CVE-2026-53239)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams\n\nsnd_pcm_drain() uses init_waitqueue_entry which does not clear\nentry.prev/next, and add_wait_queue with a conditional\nremove_wait_queue that is skipped when to_check is no longer\nin the group after concurrent UNLINK. The orphaned wait entry\nremains on the unlinked substream sleep queue. On the next\ndrain iteration, add_wait_queue adds the entry to a new queue\nwhile still linked on the old one, corrupting both lists. A\nsubsequent wake_up dereferences NULL at the func pointer\n(mapped from the spinlock at offset 0 of the misinterpreted\nwait_queue_head_t), causing a kernel panic.\n\nReplace init_waitqueue_entry/add_wait_queue/conditional\nremove_wait_queue with init_wait_entry/prepare_to_wait/\nfinish_wait. init_wait_entry clears prev/next via\nINIT_LIST_HEAD on each iteration and sets\nautoremove_wake_function which auto-removes the entry on\nwake-up. finish_wait safely handles both the already-removed\nand still-queued cases.(CVE-2026-53242)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr\n\nIn mrp_pdu_parse_vecattr(), vector attribute events are encoded three\nper byte and valen tracks the number of events left to process.\n\nThe parser decrements valen after processing the first and second events\nfrom each event byte, but not after processing the third one. When valen\nis exactly a multiple of three, the loop continues after the last valid\nevent and consumes the next byte as a new event byte, applying a\nspurious event to the MRP applicant state.\n\nAdditionally, when valen is zero the parser unconditionally consumes\nattrlen bytes as FirstValue and advances the offset, even though per\nIEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of\nzero and no FirstValue or Vector fields. This corrupts the offset for\nsubsequent PDU parsing.\n\nAlso, when valen exceeds three the loop crosses byte boundaries but\nthe attribute value is not incremented between the last event of one\nbyte and the first event of the next. This causes the first event of\nthe next byte to use the same attribute value as the third event\nrather than the next consecutive value.\n\nDecrement valen after processing the third event, skip FirstValue\nconsumption when valen is zero, and increment the attribute value at\nthe end of each loop iteration.(CVE-2026-53245)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate cached peer INIT chunk length in COOKIE_ECHO processing\n\nWhen a listening SCTP server processes a COOKIE_ECHO chunk, the cached\npeer INIT chunk embedded after the cookie is parsed and its parameters\nare later walked by sctp_process_init() using sctp_walk_params().\n\nHowever, the chunk header length of this cached INIT chunk was not\nvalidated against the remaining buffer in the COOKIE_ECHO payload. If\nthe length field is inflated, the parameter walk can run beyond the\nactual received data, leading to out-of-bounds reads and potential\nmemory corruption during later parameter handling (e.g. STATE_COOKIE\nprocessing and kmemdup() copies).\n\nAdd a bounds check in sctp_unpack_cookie() to ensure the cached INIT\nchunk length does not exceed the available data in the COOKIE_ECHO\nbuffer before it is used.(CVE-2026-53246)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: restrict IPOPT_SSRR and IPOPT_LSRR options\n\nThis patch restricts setting Loose Source and Record Route (LSRR)\nand Strict Source and Record Route (SSRR) IP options to users\nwith CAP_NET_RAW capability.\n\nThis prevents unprivileged applications from forcing packets to route\nthrough attacker-controlled nodes to leak TCP ISN and possibly other\nprotocol information.\n\nWhile LSRR and SSRR are commonly filtered in many network environments,\nthey may still be supported and forwarded along some network paths.\n\nRFC 7126 (Recommendations on Filtering of IPv4 Packets Containing\nIPv4 Options) recommend to drop these options in 4.3 and 4.4.(CVE-2026-53249)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: fix memory leak in error path of hci_alloc_dev()\n\nEarly failures in Bluetooth HCI UART configuration leak SRCU percpu\nmemory.\n\nWhen device initialization fails before hci_register_dev() completes,\nthe HCI_UNREGISTER flag is never set. As a result, when the device\nreference count reaches zero, bt_host_release() evaluates this flag as\nfalse and falls back to a direct kfree(hdev).\n\nBecause hci_release_dev() is bypassed, the SRCU struct initialized\nearly in hci_alloc_dev() is never cleaned up, resulting in a leak of\npercpu memory.\n\nFix the leak by explicitly calling cleanup_srcu_struct() in the\nfallback (unregistered) branch of bt_host_release() before freeing\nthe device.(CVE-2026-53252)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: bnep: reject short frames before parsing\n\nA BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the\npacket type byte immediately and, for control packets, reads the control\nopcode and setup UUID-size byte before proving that those bytes are\npresent. bnep_rx_control() also dereferences the control opcode without\nrejecting an empty control payload.\n\nUse skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL\nreturn gates each dereference. Split the control handler so the frame\npath can pass an opcode that has already been pulled, and keep the\nbyte-buffer wrapper for extension control payloads.\n\nFor BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the\nsetup payload. struct bnep_setup_conn_req carries destination and source\nservice UUIDs after that byte, each uuid_size bytes, so the parser now\ndocuments that tuple explicitly instead of leaving the pull length as an\nopaque multiplication.\n\nValidation reproduced this kernel report:\nKASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790\nThe buggy address belongs to the object at ffff88800c0f7908 which belongs\nto the cache kmalloc-8 of size 8\nThe buggy address is located 0 bytes to the right of allocated 1-byte\nregion [ffff88800c0f7908, ffff88800c0f7909)\nRead of size 1\nCall trace:\n dump_stack_lvl+0xb3/0x140 (?:?)\n print_address_description+0x57/0x3a0 (?:?)\n bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306)\n print_report+0xb9/0x2b0 (?:?)\n __virt_addr_valid+0x1ba/0x3a0 (?:?)\n srso_alias_return_thunk+0x5/0xfbef5 (?:?)\n kasan_addr_to_slab+0x21/0x60 (?:?)\n kasan_report+0xe0/0x110 (?:?)\n process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200)\n worker_thread+0x65c/0xe40 (?:?)\n __kthread_parkme+0x184/0x230 (?:?)\n kthread+0x35e/0x470 (?:?)\n _raw_spin_unlock_irq+0x28/0x50 (?:?)\n ret_from_fork+0x586/0x870 (?:?)\n __switch_to+0x74f/0xdc0 (?:?)\n ret_from_fork_asm+0x1a/0x30 (?:?)(CVE-2026-53253)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: validate skb length in MCC handlers\n\nThe RFCOMM MCC handlers cast skb-\u0026gt;data to protocol-specific structs\nwithout validating skb-\u0026gt;len first. A malicious remote device can send\ntruncated MCC frames and trigger out-of-bounds reads in these handlers.\n\nFix this by using skb_pull_data() to validate and access the required\ndata before dereferencing it.\n\nrfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows\n1-byte RPN requests. Handle this by validating only the DLCI byte first,\nand validating the full struct only when len \u0026gt; 1.(CVE-2026-53254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: validate advertising TLV before type checks\n\ntlv_data_is_valid() reads each advertising data field length from\ndata[i], then inspects data[i + 1] for managed EIR types before\nchecking that the current field still fits inside the supplied buffer.\n\nA malformed field whose length byte is the last byte of the buffer can\ntherefore make the parser read one byte past the advertising data.\n\nKASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING\nrequest reached that path:\n\n BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid()\n Read of size 1\n Call trace:\n tlv_data_is_valid()\n add_advertising()\n hci_mgmt_cmd()\n hci_sock_sendmsg()\n\nMove the existing element-length check before any type-octet inspection\nso each non-empty element is proven to contain its type byte before the\nparser looks at data[i + 1].(CVE-2026-53255)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()\n\nrfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock,\nbut returns the selected listener after dropping that lock without\ntaking a reference. rfcomm_connect_ind() then locks the listener,\nqueues a child socket on it, and may notify it after unlocking it.\n\nThe buggy scenario involves two paths, with each column showing the\norder within that path:\n\nrfcomm_connect_ind(): listener close:\n 1. Find parent in 1. close() enters\n rfcomm_get_sock_by_channel() rfcomm_sock_release().\n 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown()\n without pinning parent. closes the listener.\n 3. Call lock_sock(parent) and 3. rfcomm_sock_kill()\n bt_accept_enqueue(parent, unlinks and puts parent.\n sk, true).\n 4. Read parent flags and may 4. parent can be freed.\n call sk_state_change().\n\nIf close wins the race, parent can be freed before\nrfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the\ndeferred-setup callback.\n\nTake a reference on the listener before leaving rfcomm_sk_list.lock.\nAfter lock_sock() succeeds, recheck that it is still in BT_LISTEN\nbefore queueing a child, cache the deferred-setup bit while the parent\nis locked, and drop the reference after the last parent use.\n\nKASAN reported a slab-use-after-free in lock_sock_nested() from\nrfcomm_connect_ind(), with the freeing stack going through\nrfcomm_sock_kill() and rfcomm_sock_release().(CVE-2026-53256)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_api: use RCU with deferred freeing for action lifecycle\n\nWhen NEWTFILTER and DELFILTER are run concurrently it is possible to create a\nrace with an associated action.\n\nLet\u0026apos;s illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER:\n\n 0: mutex_lock() \u0026lt;-- holds the idr lock\n 0: rcu_read_lock()\n 0: p = idr_find(idr, index) \u0026lt;-- action p is valid (RCU protects IDR)\n 0: mutex_unlock() \u0026lt;-- releases the idr lock\n 1: refcount_dec_and_mutex_lock() \u0026lt;-- refcnt 1-\u0026gt;0, mutex held\n 1: idr_remove(idr, index) \u0026lt;-- Action removed from IDR\n 1: mutex_unlock() \u0026lt;-- mutex released allowing us to delete the action\n 1: tcf_action_cleanup(p); kfree(p) \u0026lt;-- Kfrees p immediately, no deferral\n 0: refcount_inc_not_zero(\u0026amp;p-\u0026gt;tcfa_refcnt) \u0026lt;-- ouch, UAF p points to freed memory\n\nThis patch fixes the race condition between NEWTFILTER and DELFILTER by\nadding struct rcu_head to tc_action used in the deferral and introducing a\ncall_rcu() in the delete path to defer the final kfree().\n\nNote: this is a revert of commit d7fb60b9cafb (\u0026quot;net_sched: get rid of tcfa_rcu\u0026quot;)\nbut also modernization/simplification to directly use kfree_rcu().\n\nLet\u0026apos;s illustrate the new restored code path:\n\n 0: rcu_read_lock()\n 1: refcount_dec_and_mutex_lock() \u0026lt;-- refcnt 1-\u0026gt;0, mutex held\n 1: idr_remove(idr, index)\n 1: mutex_unlock()\n 1: call_rcu(\u0026amp;p-\u0026gt;tcfa_rcu, tcf_action_rcu_free) \u0026lt;-- defer kfree after grace period\n 0: p = idr_find(idr, index)\n 0: refcount_inc_not_zero(\u0026amp;p-\u0026gt;tcfa_refcnt) \u0026lt;-- fails, refcnt already 0\n 1: rcu_read_unlock() \u0026lt;-- release so freeing can run after grace period\n\nAfter CPU1 calls idr_remove(), the object is no longer reachable through the IDR.\nCPU0\u0026apos;s subsequent idr_find() will return NULL, and even if it still held a\nstale pointer, the immediate kfree() is now deferred until after the RCU grace\nperiod, so no UAF can occur.(CVE-2026-53264)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: bridge: make ebt_snat ARP rewrite writable\n\nThe ebtables SNAT target keeps the Ethernet source address rewrite\nbehind skb_ensure_writable(skb, 0). This is intentional: at the bridge\nebtables hooks the Ethernet header is addressed through\nskb_mac_header()/eth_hdr(), while skb-\u0026gt;data points at the Ethernet\npayload. Asking skb_ensure_writable() for ETH_HLEN bytes would check\nthe payload, not the Ethernet header, and would reintroduce the small\npacket regression fixed by commit 63137bc5882a.\n\nHowever, the optional ARP sender hardware address rewrite is different.\nIt writes through skb_store_bits() at an offset relative to skb-\u0026gt;data:\n\n skb_store_bits(skb, sizeof(struct arphdr), info-\u0026gt;mac, ETH_ALEN)\n\nskb_header_pointer() only safely reads the ARP header; it does not make\nthe later sender hardware address range writable. If that range is\nstill held in a nonlinear skb fragment backed by a splice-imported file\npage, skb_store_bits() maps the frag page and copies the new MAC address\ndirectly into it.\n\nEnsure the ARP SHA range is writable before reading the ARP header and\nbefore calling skb_store_bits().(CVE-2026-53266)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: bail out on template ct in get eval\n\nI noticed this issue while looking at a historic syzbot report [1].\n\nA rule like the one below is enough to trigger the bug:\n\n table ip t {\n chain pre {\n type filter hook prerouting priority raw;\n ct zone set 1\n ct original saddr 1.2.3.4 accept\n }\n }\n\nThe first expression attaches a per-cpu template ct via\nnft_ct_set_zone_eval() (nf_ct_tmpl_alloc -\u0026gt; kzalloc, tuple is all\nzero, nf_ct_l3num(ct) == 0). The next expression then calls\nnft_ct_get_eval() on the same skb, treats the template as a real ct\nand hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this\noverflows past struct nft_regs on the kernel stack; with smaller\ndreg values it silently clobbers adjacent registers.\n\nReject template ct at the eval entry and in nft_ct_get_fast_eval(),\nmirroring the check nft_ct_set_eval() already has. Additionally,\nbound the address copy in NFT_CT_SRC / NFT_CT_DST by priv-\u0026gt;len\ninstead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple\nbefore pkt_to_tuple() fills in only the protocol-relevant leading\nbytes, so the trailing bytes of tuple-\u0026gt;{src,dst}.u3.all are\nwell-defined zero. priv-\u0026gt;len is validated at rule load, so the\ncopy size is now bounded by the destination register rather than\nby an untrusted field on the conntrack.\n\n[1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c(CVE-2026-53267)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: synproxy: add mutex to guard hook reference counting\n\nAs the synproxy infrastructure register netfilter hooks on-demand when a\nuser adds the first iptables target or nftables expression, if done\nconcurrently they can race each other.\n\nIntroduce a mutex to serialize the refcount control blocks access from\nboth frontends. While a per namespace mutex might be more efficient, it\nis not needed for target/expression like SYNPROXY.(CVE-2026-53269)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: clear the svc scheduler ptr early on edit\n\nip_vs_edit_service() while unbinding the old scheduler clears\nthe svc-\u0026gt;scheduler ptr after the scheduler module initiates\nRCU callbacks. This can cause packets to use the old\nscheduler at the time when svc-\u0026gt;sched_data is already freed\nafter RCU grace period.\n\nFix it by clearing the ptr early in ip_vs_unbind_scheduler(),\nbefore the done_service method schedules any RCU callbacks.\n\nAlso, if the new scheduler fails to initialize when replacing\nthe old scheduler, try to restore the old scheduler while still\nreturning the error code.(CVE-2026-53270)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: bonding: fix NULL pointer dereference in bond_do_ioctl()\n\nIn bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which\ncan return NULL if the requested interface name does not exist. However,\nthe subsequent slave_dbg() call is placed before the NULL check:\n\n slave_dev = __dev_get_by_name(net, ifr-\u0026gt;ifr_slave);\n slave_dbg(bond_dev, slave_dev, \u0026quot;slave_dev=%p:\\n\u0026quot;, slave_dev); //here\n if (!slave_dev)\n return -ENODEV;\n\nThe slave_dbg() macro expands to netdev_dbg(bond_dev, \u0026quot;(slave %s): \u0026quot; fmt,\n(slave_dev)-\u0026gt;name, ...) which unconditionally dereferences slave_dev-\u0026gt;name\nbefore the NULL check is performed. This results in a NULL pointer\ndereference kernel oops when a user calls bonding ioctl (e.g.\nSIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave\ninterface name.\n\nThis is reachable from userspace via the bonding ioctl interface with\nCAP_NET_ADMIN capability, making it a potential local denial-of-service\nvector.\n\nFix by moving the slave_dbg() call after the NULL check.(CVE-2026-53337)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack: destroy stale expectfn expectations on unregister\n\nNAT helpers such as nf_nat_h323 store a raw pointer to module text in\nexp-\u0026gt;expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister()\nonly unlinks the callback descriptor and never walks the expectation table,\nso an expectation pending at module removal survives with a dangling\nexp-\u0026gt;expectfn into freed module text.\n\nWhen the expected connection arrives, init_conntrack() invokes\nexp-\u0026gt;expectfn(), now a stale pointer into the unloaded module. Reproduced\non a KASAN build by loading the H.323 helpers, creating a Q.931\nexpectation, unloading nf_nat_h323, then connecting to the expected port:\n\n Oops: int3: 0000 [#1] SMP KASAN NOPTI\n RIP: 0010:0xffffffffa06102d1\n init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862)\n nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049)\n ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223)\n nf_hook_slow (net/netfilter/core.c:619)\n __ip_local_out (net/ipv4/ip_output.c:120)\n __tcp_transmit_skb (net/ipv4/tcp_output.c:1715)\n tcp_connect (net/ipv4/tcp_output.c:4374)\n tcp_v4_connect (net/ipv4/tcp_ipv4.c:345)\n __sys_connect (net/socket.c:2167)\n Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323]\n\nReaching the dangling state requires CAP_SYS_MODULE in the initial user\nnamespace to remove a NAT helper that still has live expectations, so this\nis a robustness fix; leaving an expectation pointing at freed text is wrong\nregardless.\n\nAdd nf_ct_helper_expectfn_destroy(), which walks the expectation table and\ndrops every expectation whose -\u0026gt;expectfn matches the descriptor being torn\ndown. Call it from each NAT helper\u0026apos;s exit path after the existing RCU grace\nperiod, so no expectation outlives the code it points at and no extra\nsynchronize_rcu() is introduced. With the fix, the same reproducer runs to\ncompletion without the Oops.(CVE-2026-53349)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()\n\nbt_accept_dequeue() unlinks a not-yet-accepted child from the parent\naccept queue and release_sock()s it before returning, so the returned\nsk has no caller reference and is unlocked.\n\nl2cap_sock_cleanup_listen() walks these children on listening-socket\nclose. A concurrent HCI disconnect drives hci_rx_work -\u0026gt;\nl2cap_conn_del() which runs l2cap_chan_del() + l2cap_sock_kill() and\nfrees the child sk and its l2cap_chan; cleanup_listen() then uses both:\n\n BUG: KASAN: slab-use-after-free in l2cap_sock_kill\n l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close\n Freed by: l2cap_conn_del -\u0026gt; l2cap_sock_close_cb -\u0026gt; l2cap_sock_kill\n\nThis is distinct from the two fixes already in this area: commit\ne83f5e24da741 (\u0026quot;Bluetooth: serialize accept_q access\u0026quot;) serialises the\naccept_q list/poll and takes temporary refs inside bt_accept_dequeue(),\nand CVE-2025-39860 serialises the userspace close()/accept() race by\ncalling cleanup_listen() under lock_sock() in l2cap_sock_release().\nNeither covers l2cap_conn_del() running from hci_rx_work, so this UAF\nstill reproduces on current bluetooth/master.\n\nTake the reference at the source: bt_accept_dequeue() does sock_hold()\nwhile sk is still locked, before release_sock(); callers sock_put().\ncleanup_listen() pins the chan with l2cap_chan_hold_unless_zero() under\na brief child sk lock (serialising vs l2cap_sock_teardown_cb()), drops\nit before l2cap_chan_lock(), and skips a duplicate l2cap_sock_kill() on\nSOCK_DEAD. conn-\u0026gt;lock is not taken here: cleanup_listen() runs under\nthe parent sk lock and that would invert\nconn-\u0026gt;lock -\u0026gt; chan-\u0026gt;lock -\u0026gt; sk_lock (lockdep).\n\nKASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced\n12 use-after-free reports per run before this change; 0, and no lockdep\nreport, over 1600+ raced iterations after it on bluetooth/master.(CVE-2026-53357)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: use chan timer to close channels in cleanup_listen()\n\nl2cap_chan_close() removes the channel from conn-\u0026gt;chan_l, which\nmust be done under conn-\u0026gt;lock. cleanup_listen() runs under the\nparent sk_lock, so acquiring conn-\u0026gt;lock would invert the\nestablished conn-\u0026gt;lock -\u0026gt; chan-\u0026gt;lock -\u0026gt; sk_lock order.\n\nInstead of calling l2cap_chan_close() directly, schedule\nl2cap_chan_timeout with delay 0 to close the channel\nasynchronously. The timeout handler already acquires conn-\u0026gt;lock\nand chan-\u0026gt;lock in the correct order.\n\nThe timer is only armed when chan-\u0026gt;conn is still set: if it is\nalready NULL, l2cap_conn_del() has already processed this channel\n(l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb),\nso there is nothing left to do. If l2cap_conn_del() races in\nafter the timer is armed, __clear_chan_timer() inside\nl2cap_chan_del() cancels it; if the timer has already fired, the\nhandler returns harmlessly because chan-\u0026gt;conn was cleared.(CVE-2026-53358)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix shadow paging use-after-free due to unexpected role\n\nCommit 0cb2af2ea66ad (\u0026quot;KVM: x86: Fix shadow paging use-after-free due\nto unexpected GFN\u0026quot;) fixed a shadow paging mismatch between stored and\ncomputed GFNs; the bug could be triggered by changing a PDE mapping from\noutside the guest, and then deleting a memslot. The rmap_remove()\ncall would miss entries created after the PDE change because the GFN\nof the leaf SPTE does not match the GFN of the struct kvm_mmu_page.\n\nA similar hole however remains if the modified PDE points to a non-leaf\npage. In this case the gfn can be made to match, but the role does not\nmatch: the original large 2MB page creates a kvm_mmu_page with direct=1,\nwhile the new 4KB needs a kvm_mmu_page with direct=0. However,\nkvm_mmu_get_child_sp() does not compare the role, and therefore reuses\nthe page.\n\nThe next step is installing a leaf (4KB) SPTE on the new path which\nrecords an rmap entry under the gfn resolved by the walk. But when\nthat child is zapped its parent kvm_mmu_page has direct=1 and\nkvm_mmu_page_get_gfn() computes the gfn for the 4KB page as\nsp-\u0026gt;gfn + index instead of using sp-\u0026gt;shadowed_translation[] (or sp-\u0026gt;gfns[]\nin older kernels). It therefore fails to remove the recorded entry.\n\nWhen the memslot is dropped the shadow page is freed but the rmap\nentry survives, as in the scenario that was already fixed. Code that\nlater walks that gfn (dirty logging, MMU notifier invalidation, and\nso on) dereferences an sptep that lies in the freed page, causing the\nuse-after-free.(CVE-2026-53359)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: fix UAF in __blkcg_rstat_flush()\n\nWhen multiple blkgs in the same blkcg are released concurrently,\na use-after-free can occur. The race happens when one blkg\u0026apos;s\n__blkcg_rstat_flush() removes another blkg\u0026apos;s iostat entries via\nllist_del_all(). The second blkg sees an empty list and proceeds\nto free itself while the first is still iterating over its entries.\n\nMove the flush from __blkg_release() (RCU callback) to blkg_release()\n(before call_rcu). This ensures the RCU grace period waits for any\nconcurrent flush\u0026apos;s rcu_read_lock() section to complete before freeing.(CVE-2026-63802)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close\n\nSince hci_dev_close_sync() can now be called during the reset path, we\nshould also set HCI_CMD_DRAIN_WORKQUEUE. This avoids queuing timeouts\nwhile the hdev workqueue is being drained.(CVE-2026-63974)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp\n\nIf dcid is received for an already-assigned destination CID the spec\nrequires that both channels to be discarded, but calling l2cap_chan_del\nmay invalidate the tmp cursor created by list_for_each_entry_safe and\nin fact it is the wrong procedure as the chan-\u0026gt;dcid may be assigned\npreviously it really needs to be disconnected.\n\nCalling l2cap_chan_clone directly may still lead to l2cap_chan_del so\ninstead schedule l2cap_chan_timeout with delay 0 to close the channel\nasynchronously.(CVE-2026-63975)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nirq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT\n\nOn PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via\nrun_irq_workd(), so irq_work_sync() uses rcuwait() to wait for BUSY==0.\n\nAfter irq_work_single() clears BUSY via atomic_cmpxchg(), it still\ndereferences @work for irq_work_is_hard() and rcuwait_wake_up().\n\nAn irq_work_sync() caller on another CPU that enters after BUSY is cleared\ncan observe BUSY==0 immediately, return, and free the work before those\naccesses complete \u2014 causing a use-after-free.\n\nFix this by wrapping run_irq_workd() in guard(rcu)() so that the entire\nirq_work_single() execution is within an RCU read-side critical\nsection. Then add synchronize_rcu() in irq_work_sync() after\nrcuwait_wait_event() to ensure the caller waits for the RCU grace period\nbefore returning, preventing premature frees.(CVE-2026-64073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrbd: eliminate a race in lock_dwork draining on unmap\n\nGiven how rbd_lock_add_request() and rbd_img_exclusive_lock() are\nwritten, lock_dwork may be (re)queued more than it\u0026apos;s actually needed:\nfor example in case a new I/O request comes in while we are in the\nmiddle of rbd_acquire_lock() on behalf of another I/O request. This is\nexpected and with rbd_release_lock() preemptively canceling lock_dwork\nis benign under normal operation.\n\nA more problematic example is maybe_kick_acquire():\n\n if (have_requests || delayed_work_pending(\u0026amp;rbd_dev-\u0026gt;lock_dwork)) {\n dout(\u0026quot;%s rbd_dev %p kicking lock_dwork\\n\u0026quot;, __func__, rbd_dev);\n mod_delayed_work(rbd_dev-\u0026gt;task_wq, \u0026amp;rbd_dev-\u0026gt;lock_dwork, 0);\n }\n\nIt\u0026apos;s not unrealistic for lock_dwork to get canceled right after\ndelayed_work_pending() returns true and for mod_delayed_work() to\nrequeue it right there anyway. This is a classic TOCTOU race.\n\nWhen it comes to unmapping the image, there is an implicit assumption\nof no self-initiated exclusive lock activity past the point of return\nfrom rbd_dev_image_unlock() which unlocks the lock if it happens to be\nheld. This unlock is assumed to be final and lock_dwork (as well as\nall other exclusive lock tasks, really) isn\u0026apos;t expected to get queued\nagain. However, lock_dwork is canceled only in cancel_tasks_sync()\n(i.e. later in the unmap sequence) and on top of that the cancellation\ncan get in effect nullified by maybe_kick_acquire(). This may result\nin rbd_acquire_lock() executing after rbd_dev_device_release() and\nrbd_dev_image_release() run and free and/or reset a bunch of things.\nOne of the possible failure modes then is a violated\n\n rbd_assert(rbd_image_format_valid(rbd_dev-\u0026gt;image_format));\n\nin rbd_dev_header_info() which is called via rbd_dev_refresh() from\nrbd_post_acquire_action().\n\nRedo exclusive lock task draining to provide saner semantics and try\nto meet the assumptions around rbd_dev_image_unlock().(CVE-2026-64112)",
"id": "OESA-2026-3204",
"modified": "2026-08-06T11:12:04Z",
"published": "2026-08-01T11:12:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3204"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71273"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31663"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43109"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43115"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43172"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43456"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45855"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46054"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46302"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52909"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52943"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52946"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52988"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52991"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53003"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53071"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53090"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53123"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53132"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53134"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53136"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53137"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53175"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53176"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53177"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53184"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53186"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53190"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53207"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53218"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53219"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53220"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53221"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53223"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53227"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53228"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53230"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53236"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53238"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53239"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53242"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53245"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53246"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53249"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53252"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53253"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53254"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53255"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53256"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53264"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53266"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53267"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53270"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53337"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53349"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53357"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53358"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53359"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63975"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64112"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-71273",
"CVE-2026-31663",
"CVE-2026-43109",
"CVE-2026-43115",
"CVE-2026-43172",
"CVE-2026-43456",
"CVE-2026-45855",
"CVE-2026-45899",
"CVE-2026-46054",
"CVE-2026-46158",
"CVE-2026-46302",
"CVE-2026-52909",
"CVE-2026-52943",
"CVE-2026-52946",
"CVE-2026-52967",
"CVE-2026-52988",
"CVE-2026-52991",
"CVE-2026-53000",
"CVE-2026-53003",
"CVE-2026-53071",
"CVE-2026-53072",
"CVE-2026-53090",
"CVE-2026-53123",
"CVE-2026-53131",
"CVE-2026-53132",
"CVE-2026-53134",
"CVE-2026-53136",
"CVE-2026-53137",
"CVE-2026-53149",
"CVE-2026-53175",
"CVE-2026-53176",
"CVE-2026-53177",
"CVE-2026-53184",
"CVE-2026-53186",
"CVE-2026-53190",
"CVE-2026-53207",
"CVE-2026-53218",
"CVE-2026-53219",
"CVE-2026-53220",
"CVE-2026-53221",
"CVE-2026-53223",
"CVE-2026-53227",
"CVE-2026-53228",
"CVE-2026-53229",
"CVE-2026-53230",
"CVE-2026-53236",
"CVE-2026-53238",
"CVE-2026-53239",
"CVE-2026-53242",
"CVE-2026-53245",
"CVE-2026-53246",
"CVE-2026-53249",
"CVE-2026-53252",
"CVE-2026-53253",
"CVE-2026-53254",
"CVE-2026-53255",
"CVE-2026-53256",
"CVE-2026-53264",
"CVE-2026-53266",
"CVE-2026-53267",
"CVE-2026-53269",
"CVE-2026-53270",
"CVE-2026-53337",
"CVE-2026-53349",
"CVE-2026-53357",
"CVE-2026-53358",
"CVE-2026-53359",
"CVE-2026-63802",
"CVE-2026-63974",
"CVE-2026-63975",
"CVE-2026-64073",
"CVE-2026-64112"
]
}
OPENSUSE-SU-2026:21388-1
Vulnerability from csaf_opensuse - Published: 2026-07-21 08:27 - Updated: 2026-09-17 17:39RHSA-2026:67471
Vulnerability from csaf_opensuse - Published: 2026-09-15 08:14 - Updated: 2026-09-25 22:55A flaw was found in the Linux kernel's `xfrm` (IP eXtensible FRamework) subsystem. This vulnerability involves a race condition where a network device's reference is released too early during packet processing after asynchronous cryptography. This premature release can lead to the system attempting to access a deallocated device, potentially causing a system crash (Denial of Service).
RHSA-2026:68531
Vulnerability from csaf_opensuse - Published: 2026-09-17 08:26 - Updated: 2026-09-25 22:55A flaw was found in the Linux kernel's `xfrm` (IP eXtensible FRamework) subsystem. This vulnerability involves a race condition where a network device's reference is released too early during packet processing after asynchronous cryptography. This premature release can lead to the system attempting to access a deallocated device, potentially causing a system crash (Denial of Service).
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.