Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2026-31393 (GCVE-0-2026-31393)
Vulnerability from cvelistv5 – Published: 2026-04-03 15:15 – Updated: 2026-08-05 12:22| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
4e8402a3f884427f9233ba436459c158d1f2e114 , < 187e6fe939295be36063a1d91f8bebee04399a8c
(git)
Affected: 4e8402a3f884427f9233ba436459c158d1f2e114 , < 5229e7d15771eac2b5886bfb1f976aea0c1eec14 (git) Affected: 4e8402a3f884427f9233ba436459c158d1f2e114 , < 3b646516cba2ebc4b51a72954903326e7c1e443f (git) Affected: 4e8402a3f884427f9233ba436459c158d1f2e114 , < 807bd1258453c4c83f6ae9dbc1e7b44860ff40d0 (git) Affected: 4e8402a3f884427f9233ba436459c158d1f2e114 , < 9aeacde4da0f02d42fd968fd32f245828b230171 (git) Affected: 4e8402a3f884427f9233ba436459c158d1f2e114 , < e7ff754e339e3d5ce29aa9f95352d0186df8fbd9 (git) Affected: 4e8402a3f884427f9233ba436459c158d1f2e114 , < db2872d054e467810078e2b9f440a5b326a601b2 (git) Affected: 4e8402a3f884427f9233ba436459c158d1f2e114 , < dd815e6e3918dc75a49aaabac36e4f024d675101 (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.24
Unaffected: 0 , < 2.6.24 (semver) Unaffected: 5.10.253 , ≤ 5.10.* (semver) Unaffected: 5.15.203 , ≤ 5.15.* (semver) Unaffected: 6.1.167 , ≤ 6.1.* (semver) Unaffected: 6.6.130 , ≤ 6.6.* (semver) Unaffected: 6.12.78 , ≤ 6.12.* (semver) Unaffected: 6.18.20 , ≤ 6.18.* (semver) Unaffected: 6.19.10 , ≤ 6.19.* (semver) Unaffected: 7.0 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/bluetooth/l2cap_core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "187e6fe939295be36063a1d91f8bebee04399a8c",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "5229e7d15771eac2b5886bfb1f976aea0c1eec14",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "3b646516cba2ebc4b51a72954903326e7c1e443f",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "807bd1258453c4c83f6ae9dbc1e7b44860ff40d0",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "9aeacde4da0f02d42fd968fd32f245828b230171",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "e7ff754e339e3d5ce29aa9f95352d0186df8fbd9",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "db2872d054e467810078e2b9f440a5b326a601b2",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "dd815e6e3918dc75a49aaabac36e4f024d675101",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/bluetooth/l2cap_core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.24"
},
{
"lessThan": "2.6.24",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.253",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.203",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.167",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.130",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.78",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.20",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.253",
"versionStartIncluding": "2.6.24",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.203",
"versionStartIncluding": "2.6.24",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.167",
"versionStartIncluding": "2.6.24",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.130",
"versionStartIncluding": "2.6.24",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.78",
"versionStartIncluding": "2.6.24",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.20",
"versionStartIncluding": "2.6.24",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19.10",
"versionStartIncluding": "2.6.24",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0",
"versionStartIncluding": "2.6.24",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access\n\nl2cap_information_rsp() checks that cmd_len covers the fixed\nl2cap_info_rsp header (type + result, 4 bytes) but then reads\nrsp-\u003edata without verifying that the payload is present:\n\n - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp-\u003edata), which reads\n 4 bytes past the header (needs cmd_len \u003e= 8).\n\n - L2CAP_IT_FIXED_CHAN reads rsp-\u003edata[0], 1 byte past the header\n (needs cmd_len \u003e= 5).\n\nA truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an\nout-of-bounds read of adjacent skb data.\n\nGuard each data access with the required payload length check. If the\npayload is too short, skip the read and let the state machine complete\nwith safe defaults (feat_mask and remote_fixed_chan remain zero from\nkzalloc), so the info timer cleanup and l2cap_conn_start() still run\nand the connection is not stalled."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 8.1,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:A - The vulnerable parser is reached by Bluetooth BR/EDR L2CAP signaling over an ACL link, so an attacker must be within Bluetooth radio range rather than on a routed IP network.\nAC:L - The attacker controls the malformed L2CAP_INFO_RSP payload and sees the kernel\u0027s request identifier before responding. No race or unusual condition beyond establishing the Bluetooth link is required.\nPR:N - The L2CAP information exchange occurs during connection setup before L2CAP channel security/authentication gates are enforced. A malicious adjacent Bluetooth peer does not need local credentials or kernel privileges on the victim.\nUI:N - In a reasonable connectable Bluetooth deployment, the peer can trigger the receive path by establishing or participating in an ACL/L2CAP connection. No victim user action is required for the malformed response itself.\nS:U - The bug is in the kernel Bluetooth stack and impacts kernel-managed resources in the same security authority. It does not cross a VM, IOMMU, or other separate security boundary.\nC:H - The bug performs an out-of-bounds read from skb-adjacent data past the declared L2CAP_INFO_RSP payload. Under the required conservative scoring for kernel out-of-bounds reads, this is treated as high confidentiality impact.\nI:N - The flaw is an out-of-bounds read, not a write or type confusion primitive. It can corrupt protocol state selection, but does not provide a defensible arbitrary modification or code execution primitive.\nA:H - Reading past the valid skb data can trigger a kernel fault, KASAN report, oops, or panic on hardened/debug configurations. An adjacent peer can repeat the malformed response during connection setup, so availability impact is high."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T12:22:04.813Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/187e6fe939295be36063a1d91f8bebee04399a8c"
},
{
"url": "https://git.kernel.org/stable/c/5229e7d15771eac2b5886bfb1f976aea0c1eec14"
},
{
"url": "https://git.kernel.org/stable/c/3b646516cba2ebc4b51a72954903326e7c1e443f"
},
{
"url": "https://git.kernel.org/stable/c/807bd1258453c4c83f6ae9dbc1e7b44860ff40d0"
},
{
"url": "https://git.kernel.org/stable/c/9aeacde4da0f02d42fd968fd32f245828b230171"
},
{
"url": "https://git.kernel.org/stable/c/e7ff754e339e3d5ce29aa9f95352d0186df8fbd9"
},
{
"url": "https://git.kernel.org/stable/c/db2872d054e467810078e2b9f440a5b326a601b2"
},
{
"url": "https://git.kernel.org/stable/c/dd815e6e3918dc75a49aaabac36e4f024d675101"
}
],
"title": "Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-31393",
"datePublished": "2026-04-03T15:15:58.142Z",
"dateReserved": "2026-03-09T15:48:24.085Z",
"dateUpdated": "2026-08-05T12:22:04.813Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-31393",
"date": "2026-09-23",
"epss": "0.00255",
"percentile": "0.17429"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/bluetooth/l2cap_core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "187e6fe939295be36063a1d91f8bebee04399a8c",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "5229e7d15771eac2b5886bfb1f976aea0c1eec14",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "3b646516cba2ebc4b51a72954903326e7c1e443f",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "807bd1258453c4c83f6ae9dbc1e7b44860ff40d0",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "9aeacde4da0f02d42fd968fd32f245828b230171",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "e7ff754e339e3d5ce29aa9f95352d0186df8fbd9",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "db2872d054e467810078e2b9f440a5b326a601b2",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "dd815e6e3918dc75a49aaabac36e4f024d675101",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/bluetooth/l2cap_core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.24"
},
{
"lessThan": "2.6.24",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.253",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.203",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.167",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.130",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.78",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.20",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "23F88A56-E27D-46A7-B32C-65333C046B72",
"versionEndExcluding": "5.10.253",
"versionStartIncluding": "2.6.24",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "20DDB3E9-AABF-4107-ADB0-5362AA067045",
"versionEndExcluding": "5.15.203",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "2EDC6BAF-B710-4E26-B6AA-D68922EE7B43",
"versionEndExcluding": "6.1.167",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C57BB918-DF28-46B3-94F7-144176841267",
"versionEndExcluding": "6.6.130",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "28D591F5-B196-4CC9-905C-DC80F116E7A8",
"versionEndExcluding": "6.12.78",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E5571059-6552-48E7-9BEF-3E358C387171",
"versionEndExcluding": "6.18.20",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "96D34333-38BE-4414-9E79-6EB764329581",
"versionEndExcluding": "6.19.10",
"versionStartIncluding": "6.19",
"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
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access\n\nl2cap_information_rsp() checks that cmd_len covers the fixed\nl2cap_info_rsp header (type + result, 4 bytes) but then reads\nrsp-\u003edata without verifying that the payload is present:\n\n - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp-\u003edata), which reads\n 4 bytes past the header (needs cmd_len \u003e= 8).\n\n - L2CAP_IT_FIXED_CHAN reads rsp-\u003edata[0], 1 byte past the header\n (needs cmd_len \u003e= 5).\n\nA truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an\nout-of-bounds read of adjacent skb data.\n\nGuard each data access with the required payload length check. If the\npayload is too short, skip the read and let the state machine complete\nwith safe defaults (feat_mask and remote_fixed_chan remain zero from\nkzalloc), so the info timer cleanup and l2cap_conn_start() still run\nand the connection is not stalled."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nBluetooth: L2CAP: Validar la longitud de la carga \u00fatil de L2CAP_INFO_RSP antes del acceso\n\nl2cap_information_rsp() comprueba que cmd_len cubre la cabecera fija de l2cap_info_rsp (tipo + resultado, 4 bytes) pero luego lee rsp -\u003e data sin verificar que la carga \u00fatil est\u00e9 presente:\n\n - L2CAP_IT_FEAT_MASK llama a get_unaligned_le32(rsp -\u003e data), que lee 4 bytes despu\u00e9s de la cabecera (necesita cmd_len \u003e= 8).\n\n - L2CAP_IT_FIXED_CHAN lee rsp -\u003e data[0], 1 byte despu\u00e9s de la cabecera (necesita cmd_len \u003e= 5).\n\nUn L2CAP_INFO_RSP truncado con result == L2CAP_IR_SUCCESS desencadena una lectura fuera de l\u00edmites de datos skb adyacentes.\n\nProteger cada acceso a datos con la comprobaci\u00f3n de longitud de carga \u00fatil requerida. Si la carga \u00fatil es demasiado corta, omitir la lectura y permitir que la m\u00e1quina de estados se complete con valores predeterminados seguros (feat_mask y remote_fixed_chan permanecen en cero desde kzalloc), para que la limpieza del temporizador de informaci\u00f3n y l2cap_conn_start() sigan ejecut\u00e1ndose y la conexi\u00f3n no se estanque."
}
],
"id": "CVE-2026-31393",
"lastModified": "2026-07-24T22:10:00.140",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 2.8,
"impactScore": 5.2,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2026-04-03T16:16:37.420",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/187e6fe939295be36063a1d91f8bebee04399a8c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3b646516cba2ebc4b51a72954903326e7c1e443f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5229e7d15771eac2b5886bfb1f976aea0c1eec14"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/807bd1258453c4c83f6ae9dbc1e7b44860ff40d0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/9aeacde4da0f02d42fd968fd32f245828b230171"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/db2872d054e467810078e2b9f440a5b326a601b2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/dd815e6e3918dc75a49aaabac36e4f024d675101"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e7ff754e339e3d5ce29aa9f95352d0186df8fbd9"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-30T11:46:39+00:00",
"cve": "CVE-2026-31393",
"id": "CVE-2026-31393",
"initial_release_date": "2026-04-03T00:00:00+00:00",
"product_status:known_affected": "260",
"product_status:known_not_affected": "14",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-31393.json",
"version": "3"
}
}
}
CERTFR-2026-AVI-1093
Vulnerability from certfr_avis - Published: 2026-08-28 - Updated: 2026-08-28
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
None{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 26.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 14.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": null,
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2026-46325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46325"
},
{
"name": "CVE-2026-31623",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31623"
},
{
"name": "CVE-2026-43198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43198"
},
{
"name": "CVE-2026-45842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45842"
},
{
"name": "CVE-2026-31483",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31483"
},
{
"name": "CVE-2026-64046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64046"
},
{
"name": "CVE-2026-43135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43135"
},
{
"name": "CVE-2026-31409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31409"
},
{
"name": "CVE-2026-45864",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45864"
},
{
"name": "CVE-2026-43113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43113"
},
{
"name": "CVE-2026-31522",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31522"
},
{
"name": "CVE-2025-71187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71187"
},
{
"name": "CVE-2026-43068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43068"
},
{
"name": "CVE-2026-23167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23167"
},
{
"name": "CVE-2026-31770",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31770"
},
{
"name": "CVE-2024-46770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46770"
},
{
"name": "CVE-2026-46119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46119"
},
{
"name": "CVE-2026-23129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23129"
},
{
"name": "CVE-2026-46184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46184"
},
{
"name": "CVE-2026-64133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64133"
},
{
"name": "CVE-2026-53049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53049"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2026-31619",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31619"
},
{
"name": "CVE-2026-31658",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31658"
},
{
"name": "CVE-2026-64047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64047"
},
{
"name": "CVE-2026-31618",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31618"
},
{
"name": "CVE-2026-31756",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31756"
},
{
"name": "CVE-2026-31467",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31467"
},
{
"name": "CVE-2026-52955",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52955"
},
{
"name": "CVE-2026-23318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23318"
},
{
"name": "CVE-2026-23098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23098"
},
{
"name": "CVE-2026-23092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23092"
},
{
"name": "CVE-2026-23368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23368"
},
{
"name": "CVE-2026-43270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43270"
},
{
"name": "CVE-2026-46328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46328"
},
{
"name": "CVE-2026-52957",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52957"
},
{
"name": "CVE-2026-52925",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52925"
},
{
"name": "CVE-2026-23079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23079"
},
{
"name": "CVE-2026-43227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43227"
},
{
"name": "CVE-2026-46307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46307"
},
{
"name": "CVE-2025-27558",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27558"
},
{
"name": "CVE-2026-53061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53061"
},
{
"name": "CVE-2026-43315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43315"
},
{
"name": "CVE-2026-31485",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31485"
},
{
"name": "CVE-2026-23022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23022"
},
{
"name": "CVE-2026-43314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43314"
},
{
"name": "CVE-2026-43373",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43373"
},
{
"name": "CVE-2026-53002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53002"
},
{
"name": "CVE-2026-23126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23126"
},
{
"name": "CVE-2026-53287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53287"
},
{
"name": "CVE-2026-46124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46124"
},
{
"name": "CVE-2026-31578",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31578"
},
{
"name": "CVE-2026-46082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46082"
},
{
"name": "CVE-2026-43251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43251"
},
{
"name": "CVE-2026-23054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23054"
},
{
"name": "CVE-2026-31754",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31754"
},
{
"name": "CVE-2026-53128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53128"
},
{
"name": "CVE-2026-23014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23014"
},
{
"name": "CVE-2026-43211",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43211"
},
{
"name": "CVE-2026-53320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53320"
},
{
"name": "CVE-2026-31402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31402"
},
{
"name": "CVE-2026-23122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23122"
},
{
"name": "CVE-2026-23072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23072"
},
{
"name": "CVE-2024-56727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56727"
},
{
"name": "CVE-2026-45852",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45852"
},
{
"name": "CVE-2026-31758",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31758"
},
{
"name": "CVE-2026-23159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23159"
},
{
"name": "CVE-2026-45856",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45856"
},
{
"name": "CVE-2024-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53221"
},
{
"name": "CVE-2025-71265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71265"
},
{
"name": "CVE-2026-23045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23045"
},
{
"name": "CVE-2026-53041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53041"
},
{
"name": "CVE-2026-23281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23281"
},
{
"name": "CVE-2026-64179",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64179"
},
{
"name": "CVE-2026-31696",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31696"
},
{
"name": "CVE-2026-43168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43168"
},
{
"name": "CVE-2026-43060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43060"
},
{
"name": "CVE-2026-23114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23114"
},
{
"name": "CVE-2025-71221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71221"
},
{
"name": "CVE-2026-52970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52970"
},
{
"name": "CVE-2026-52958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52958"
},
{
"name": "CVE-2023-53629",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53629"
},
{
"name": "CVE-2026-46319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46319"
},
{
"name": "CVE-2026-31416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31416"
},
{
"name": "CVE-2026-23069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23069"
},
{
"name": "CVE-2026-64531",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64531"
},
{
"name": "CVE-2026-31656",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31656"
},
{
"name": "CVE-2026-52999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52999"
},
{
"name": "CVE-2026-22992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22992"
},
{
"name": "CVE-2026-46227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46227"
},
{
"name": "CVE-2025-39764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39764"
},
{
"name": "CVE-2026-23004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23004"
},
{
"name": "CVE-2026-43241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43241"
},
{
"name": "CVE-2025-71191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71191"
},
{
"name": "CVE-2026-53040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53040"
},
{
"name": "CVE-2026-23438",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23438"
},
{
"name": "CVE-2026-43062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43062"
},
{
"name": "CVE-2026-23293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23293"
},
{
"name": "CVE-2026-23463",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23463"
},
{
"name": "CVE-2026-23227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23227"
},
{
"name": "CVE-2026-46185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46185"
},
{
"name": "CVE-2026-43145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43145"
},
{
"name": "CVE-2026-46253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46253"
},
{
"name": "CVE-2026-23454",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23454"
},
{
"name": "CVE-2026-31405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31405"
},
{
"name": "CVE-2026-43136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43136"
},
{
"name": "CVE-2026-23009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23009"
},
{
"name": "CVE-2026-43339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43339"
},
{
"name": "CVE-2026-64221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64221"
},
{
"name": "CVE-2026-43054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43054"
},
{
"name": "CVE-2026-46064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46064"
},
{
"name": "CVE-2026-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23143"
},
{
"name": "CVE-2026-45988",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45988"
},
{
"name": "CVE-2026-31698",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31698"
},
{
"name": "CVE-2026-31664",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31664"
},
{
"name": "CVE-2026-45868",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45868"
},
{
"name": "CVE-2026-46112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46112"
},
{
"name": "CVE-2024-27389",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27389"
},
{
"name": "CVE-2026-31473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31473"
},
{
"name": "CVE-2026-43123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43123"
},
{
"name": "CVE-2026-31448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31448"
},
{
"name": "CVE-2026-31597",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31597"
},
{
"name": "CVE-2026-22981",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22981"
},
{
"name": "CVE-2026-31550",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31550"
},
{
"name": "CVE-2026-23220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23220"
},
{
"name": "CVE-2026-23290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23290"
},
{
"name": "CVE-2026-31549",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31549"
},
{
"name": "CVE-2025-40103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40103"
},
{
"name": "CVE-2026-23020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23020"
},
{
"name": "CVE-2026-31752",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31752"
},
{
"name": "CVE-2025-40016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40016"
},
{
"name": "CVE-2025-38626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38626"
},
{
"name": "CVE-2026-43476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43476"
},
{
"name": "CVE-2026-43202",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43202"
},
{
"name": "CVE-2026-52989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52989"
},
{
"name": "CVE-2026-53291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53291"
},
{
"name": "CVE-2025-71201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71201"
},
{
"name": "CVE-2026-52924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52924"
},
{
"name": "CVE-2026-23303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23303"
},
{
"name": "CVE-2026-43011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43011"
},
{
"name": "CVE-2026-43132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43132"
},
{
"name": "CVE-2026-31396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31396"
},
{
"name": "CVE-2026-23136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23136"
},
{
"name": "CVE-2026-23139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23139"
},
{
"name": "CVE-2026-31680",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31680"
},
{
"name": "CVE-2026-23017",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23017"
},
{
"name": "CVE-2026-31586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31586"
},
{
"name": "CVE-2026-43465",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43465"
},
{
"name": "CVE-2026-23340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23340"
},
{
"name": "CVE-2026-43046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43046"
},
{
"name": "CVE-2026-46233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46233"
},
{
"name": "CVE-2025-71189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71189"
},
{
"name": "CVE-2026-52963",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52963"
},
{
"name": "CVE-2026-46303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46303"
},
{
"name": "CVE-2026-23090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23090"
},
{
"name": "CVE-2026-43163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43163"
},
{
"name": "CVE-2026-23007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23007"
},
{
"name": "CVE-2026-31738",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31738"
},
{
"name": "CVE-2026-23035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23035"
},
{
"name": "CVE-2025-68307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68307"
},
{
"name": "CVE-2025-40005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40005"
},
{
"name": "CVE-2026-43411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43411"
},
{
"name": "CVE-2026-31751",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31751"
},
{
"name": "CVE-2026-43429",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43429"
},
{
"name": "CVE-2026-53224",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53224"
},
{
"name": "CVE-2026-52993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52993"
},
{
"name": "CVE-2026-46080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46080"
},
{
"name": "CVE-2026-23064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23064"
},
{
"name": "CVE-2025-71287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71287"
},
{
"name": "CVE-2026-46231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46231"
},
{
"name": "CVE-2026-45835",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45835"
},
{
"name": "CVE-2026-43382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43382"
},
{
"name": "CVE-2026-22987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22987"
},
{
"name": "CVE-2026-23439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23439"
},
{
"name": "CVE-2026-23253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23253"
},
{
"name": "CVE-2026-31581",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31581"
},
{
"name": "CVE-2026-31721",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31721"
},
{
"name": "CVE-2026-23061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23061"
},
{
"name": "CVE-2026-23059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23059"
},
{
"name": "CVE-2026-31617",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31617"
},
{
"name": "CVE-2026-23115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23115"
},
{
"name": "CVE-2026-31687",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31687"
},
{
"name": "CVE-2026-46019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46019"
},
{
"name": "CVE-2026-43052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43052"
},
{
"name": "CVE-2026-43496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43496"
},
{
"name": "CVE-2026-64178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64178"
},
{
"name": "CVE-2026-23135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23135"
},
{
"name": "CVE-2026-43324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43324"
},
{
"name": "CVE-2026-52915",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52915"
},
{
"name": "CVE-2026-64177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64177"
},
{
"name": "CVE-2026-23047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23047"
},
{
"name": "CVE-2026-46195",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46195"
},
{
"name": "CVE-2026-46214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46214"
},
{
"name": "CVE-2026-23119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23119"
},
{
"name": "CVE-2026-23173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23173"
},
{
"name": "CVE-2026-23434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23434"
},
{
"name": "CVE-2026-23123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23123"
},
{
"name": "CVE-2026-23137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23137"
},
{
"name": "CVE-2026-43014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43014"
},
{
"name": "CVE-2026-43139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43139"
},
{
"name": "CVE-2026-45873",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45873"
},
{
"name": "CVE-2026-23222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23222"
},
{
"name": "CVE-2026-31447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31447"
},
{
"name": "CVE-2026-45870",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45870"
},
{
"name": "CVE-2026-31431",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31431"
},
{
"name": "CVE-2026-46027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46027"
},
{
"name": "CVE-2026-53309",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53309"
},
{
"name": "CVE-2026-43445",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43445"
},
{
"name": "CVE-2026-23094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23094"
},
{
"name": "CVE-2026-23049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23049"
},
{
"name": "CVE-2026-43387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43387"
},
{
"name": "CVE-2026-31599",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31599"
},
{
"name": "CVE-2025-21712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21712"
},
{
"name": "CVE-2026-43028",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43028"
},
{
"name": "CVE-2026-46040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46040"
},
{
"name": "CVE-2026-46236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46236"
},
{
"name": "CVE-2026-45871",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45871"
},
{
"name": "CVE-2026-23229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23229"
},
{
"name": "CVE-2026-43475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43475"
},
{
"name": "CVE-2026-23042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23042"
},
{
"name": "CVE-2026-46113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46113"
},
{
"name": "CVE-2025-38710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38710"
},
{
"name": "CVE-2026-23304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23304"
},
{
"name": "CVE-2026-31683",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31683"
},
{
"name": "CVE-2024-56557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56557"
},
{
"name": "CVE-2026-43262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43262"
},
{
"name": "CVE-2026-64220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64220"
},
{
"name": "CVE-2026-23101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23101"
},
{
"name": "CVE-2026-23357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23357"
},
{
"name": "CVE-2026-45946",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45946"
},
{
"name": "CVE-2026-23099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23099"
},
{
"name": "CVE-2026-45860",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45860"
},
{
"name": "CVE-2026-31408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31408"
},
{
"name": "CVE-2026-43279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43279"
},
{
"name": "CVE-2026-43058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43058"
},
{
"name": "CVE-2026-46137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46137"
},
{
"name": "CVE-2025-38105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38105"
},
{
"name": "CVE-2026-53071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53071"
},
{
"name": "CVE-2026-45841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45841"
},
{
"name": "CVE-2026-31524",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31524"
},
{
"name": "CVE-2026-46072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46072"
},
{
"name": "CVE-2026-43231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43231"
},
{
"name": "CVE-2026-31668",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31668"
},
{
"name": "CVE-2026-23066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23066"
},
{
"name": "CVE-2025-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38562"
},
{
"name": "CVE-2026-31478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31478"
},
{
"name": "CVE-2026-31546",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31546"
},
{
"name": "CVE-2026-45956",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45956"
},
{
"name": "CVE-2026-46331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46331"
},
{
"name": "CVE-2026-22989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22989"
},
{
"name": "CVE-2026-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23085"
},
{
"name": "CVE-2023-52737",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52737"
},
{
"name": "CVE-2025-54505",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54505"
},
{
"name": "CVE-2026-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23150"
},
{
"name": "CVE-2026-64165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64165"
},
{
"name": "CVE-2026-31583",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31583"
},
{
"name": "CVE-2026-53064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53064"
},
{
"name": "CVE-2026-31605",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31605"
},
{
"name": "CVE-2026-23324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23324"
},
{
"name": "CVE-2026-23236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23236"
},
{
"name": "CVE-2026-23109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23109"
},
{
"name": "CVE-2026-52995",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52995"
},
{
"name": "CVE-2026-46209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46209"
},
{
"name": "CVE-2026-52931",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52931"
},
{
"name": "CVE-2026-23130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23130"
},
{
"name": "CVE-2026-23163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23163"
},
{
"name": "CVE-2026-43047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43047"
},
{
"name": "CVE-2026-53047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53047"
},
{
"name": "CVE-2025-71235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71235"
},
{
"name": "CVE-2026-43432",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43432"
},
{
"name": "CVE-2026-45866",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45866"
},
{
"name": "CVE-2026-53296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53296"
},
{
"name": "CVE-2026-23057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23057"
},
{
"name": "CVE-2024-46715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46715"
},
{
"name": "CVE-2026-31545",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31545"
},
{
"name": "CVE-2026-31681",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31681"
},
{
"name": "CVE-2026-31598",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31598"
},
{
"name": "CVE-2026-23456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23456"
},
{
"name": "CVE-2026-46186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46186"
},
{
"name": "CVE-2026-43458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43458"
},
{
"name": "CVE-2026-23166",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23166"
},
{
"name": "CVE-2026-52919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52919"
},
{
"name": "CVE-2026-53006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53006"
},
{
"name": "CVE-2026-43450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43450"
},
{
"name": "CVE-2026-31510",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31510"
},
{
"name": "CVE-2026-31622",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31622"
},
{
"name": "CVE-2026-22991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22991"
},
{
"name": "CVE-2026-43079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43079"
},
{
"name": "CVE-2026-23457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23457"
},
{
"name": "CVE-2026-23081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23081"
},
{
"name": "CVE-2026-64102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64102"
},
{
"name": "CVE-2026-46002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46002"
},
{
"name": "CVE-2026-46101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46101"
},
{
"name": "CVE-2026-46099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46099"
},
{
"name": "CVE-2026-43103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43103"
},
{
"name": "CVE-2026-43069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43069"
},
{
"name": "CVE-2026-43425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43425"
},
{
"name": "CVE-2026-31642",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31642"
},
{
"name": "CVE-2026-46024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46024"
},
{
"name": "CVE-2026-23399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23399"
},
{
"name": "CVE-2026-23012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23012"
},
{
"name": "CVE-2026-23116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23116"
},
{
"name": "CVE-2026-31659",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31659"
},
{
"name": "CVE-2026-31701",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31701"
},
{
"name": "CVE-2026-45847",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45847"
},
{
"name": "CVE-2024-50012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50012"
},
{
"name": "CVE-2026-43480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43480"
},
{
"name": "CVE-2026-64083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64083"
},
{
"name": "CVE-2026-23401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23401"
},
{
"name": "CVE-2025-71239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71239"
},
{
"name": "CVE-2026-46037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46037"
},
{
"name": "CVE-2026-43268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43268"
},
{
"name": "CVE-2026-53048",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53048"
},
{
"name": "CVE-2025-71200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71200"
},
{
"name": "CVE-2026-43426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43426"
},
{
"name": "CVE-2026-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53176"
},
{
"name": "CVE-2026-43030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43030"
},
{
"name": "CVE-2024-36898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36898"
},
{
"name": "CVE-2026-43074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43074"
},
{
"name": "CVE-2026-46151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46151"
},
{
"name": "CVE-2026-22980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22980"
},
{
"name": "CVE-2026-23138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23138"
},
{
"name": "CVE-2026-23172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23172"
},
{
"name": "CVE-2026-23046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23046"
},
{
"name": "CVE-2026-43493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43493"
},
{
"name": "CVE-2026-45912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45912"
},
{
"name": "CVE-2026-45911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45911"
},
{
"name": "CVE-2025-38250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38250"
},
{
"name": "CVE-2026-46220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46220"
},
{
"name": "CVE-2026-46259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46259"
},
{
"name": "CVE-2026-31588",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31588"
},
{
"name": "CVE-2026-43334",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43334"
},
{
"name": "CVE-2026-23234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23234"
},
{
"name": "CVE-2026-23391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23391"
},
{
"name": "CVE-2026-31415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31415"
},
{
"name": "CVE-2026-46127",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46127"
},
{
"name": "CVE-2026-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23133"
},
{
"name": "CVE-2026-45869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45869"
},
{
"name": "CVE-2026-23131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23131"
},
{
"name": "CVE-2026-23212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23212"
},
{
"name": "CVE-2026-23032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23032"
},
{
"name": "CVE-2026-23170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23170"
},
{
"name": "CVE-2024-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47809"
},
{
"name": "CVE-2026-23204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23204"
},
{
"name": "CVE-2026-23462",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23462"
},
{
"name": "CVE-2026-53046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53046"
},
{
"name": "CVE-2026-53050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53050"
},
{
"name": "CVE-2026-23019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23019"
},
{
"name": "CVE-2026-23372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23372"
},
{
"name": "CVE-2026-43080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43080"
},
{
"name": "CVE-2026-46146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46146"
},
{
"name": "CVE-2025-71188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71188"
},
{
"name": "CVE-2026-45836",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45836"
},
{
"name": "CVE-2026-64039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64039"
},
{
"name": "CVE-2026-23055",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23055"
},
{
"name": "CVE-2026-46178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46178"
},
{
"name": "CVE-2026-45846",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45846"
},
{
"name": "CVE-2026-45919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45919"
},
{
"name": "CVE-2026-43499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43499"
},
{
"name": "CVE-2026-23125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23125"
},
{
"name": "CVE-2026-45862",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45862"
},
{
"name": "CVE-2026-46174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46174"
},
{
"name": "CVE-2026-53021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53021"
},
{
"name": "CVE-2026-43200",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43200"
},
{
"name": "CVE-2026-45857",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45857"
},
{
"name": "CVE-2026-45848",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45848"
},
{
"name": "CVE-2026-43327",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43327"
},
{
"name": "CVE-2026-23005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23005"
},
{
"name": "CVE-2024-56719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56719"
},
{
"name": "CVE-2026-46133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46133"
},
{
"name": "CVE-2026-31494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31494"
},
{
"name": "CVE-2026-31565",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31565"
},
{
"name": "CVE-2026-31697",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31697"
},
{
"name": "CVE-2026-43381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43381"
},
{
"name": "CVE-2026-23270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23270"
},
{
"name": "CVE-2026-31763",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31763"
},
{
"name": "CVE-2026-23030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23030"
},
{
"name": "CVE-2026-23279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23279"
},
{
"name": "CVE-2026-22997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22997"
},
{
"name": "CVE-2026-31616",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31616"
},
{
"name": "CVE-2026-31670",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31670"
},
{
"name": "CVE-2026-46122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46122"
},
{
"name": "CVE-2026-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53131"
},
{
"name": "CVE-2026-23228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23228"
},
{
"name": "CVE-2026-46022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46022"
},
{
"name": "CVE-2025-71196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71196"
},
{
"name": "CVE-2026-63865",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63865"
},
{
"name": "CVE-2026-31422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31422"
},
{
"name": "CVE-2025-71304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71304"
},
{
"name": "CVE-2026-23286",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23286"
},
{
"name": "CVE-2026-23359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23359"
},
{
"name": "CVE-2026-43232",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43232"
},
{
"name": "CVE-2026-23298",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23298"
},
{
"name": "CVE-2026-31469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31469"
},
{
"name": "CVE-2026-45867",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45867"
},
{
"name": "CVE-2026-43264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43264"
},
{
"name": "CVE-2026-31498",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31498"
},
{
"name": "CVE-2026-31615",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31615"
},
{
"name": "CVE-2026-45879",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45879"
},
{
"name": "CVE-2026-45883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45883"
},
{
"name": "CVE-2026-64085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64085"
},
{
"name": "CVE-2026-46043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46043"
},
{
"name": "CVE-2026-46120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46120"
},
{
"name": "CVE-2026-46198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46198"
},
{
"name": "CVE-2026-43336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43336"
},
{
"name": "CVE-2026-43104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43104"
},
{
"name": "CVE-2026-52954",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52954"
},
{
"name": "CVE-2026-23078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23078"
},
{
"name": "CVE-2026-43269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43269"
},
{
"name": "CVE-2026-64166",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64166"
},
{
"name": "CVE-2026-46189",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46189"
},
{
"name": "CVE-2026-23169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23169"
},
{
"name": "CVE-2026-43466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43466"
},
{
"name": "CVE-2026-43197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43197"
},
{
"name": "CVE-2026-23296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23296"
},
{
"name": "CVE-2026-53130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53130"
},
{
"name": "CVE-2026-46128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46128"
},
{
"name": "CVE-2026-52984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52984"
},
{
"name": "CVE-2026-31427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31427"
},
{
"name": "CVE-2026-53088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53088"
},
{
"name": "CVE-2026-31555",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31555"
},
{
"name": "CVE-2026-31594",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31594"
},
{
"name": "CVE-2026-46317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46317"
},
{
"name": "CVE-2026-64155",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64155"
},
{
"name": "CVE-2026-43439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43439"
},
{
"name": "CVE-2022-50073",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50073"
},
{
"name": "CVE-2026-43183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43183"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-31580",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31580"
},
{
"name": "CVE-2026-43099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43099"
},
{
"name": "CVE-2026-46242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46242"
},
{
"name": "CVE-2026-53065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53065"
},
{
"name": "CVE-2025-71199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71199"
},
{
"name": "CVE-2026-31515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31515"
},
{
"name": "CVE-2026-31661",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31661"
},
{
"name": "CVE-2026-43380",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43380"
},
{
"name": "CVE-2026-43452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43452"
},
{
"name": "CVE-2026-31737",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31737"
},
{
"name": "CVE-2025-68358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68358"
},
{
"name": "CVE-2026-46197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46197"
},
{
"name": "CVE-2026-46301",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46301"
},
{
"name": "CVE-2026-52914",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52914"
},
{
"name": "CVE-2026-52916",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52916"
},
{
"name": "CVE-2026-53225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53225"
},
{
"name": "CVE-2026-23006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23006"
},
{
"name": "CVE-2026-53294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53294"
},
{
"name": "CVE-2026-23165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23165"
},
{
"name": "CVE-2026-45960",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45960"
},
{
"name": "CVE-2026-23013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23013"
},
{
"name": "CVE-2025-71267",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71267"
},
{
"name": "CVE-2026-64125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64125"
},
{
"name": "CVE-2026-43043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43043"
},
{
"name": "CVE-2025-71195",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71195"
},
{
"name": "CVE-2026-22994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22994"
},
{
"name": "CVE-2026-31705",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31705"
},
{
"name": "CVE-2026-43140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43140"
},
{
"name": "CVE-2026-43223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43223"
},
{
"name": "CVE-2026-31684",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31684"
},
{
"name": "CVE-2026-43205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43205"
},
{
"name": "CVE-2026-23396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23396"
},
{
"name": "CVE-2026-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23083"
},
{
"name": "CVE-2026-31423",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31423"
},
{
"name": "CVE-2026-52922",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52922"
},
{
"name": "CVE-2026-23088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23088"
},
{
"name": "CVE-2026-64089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64089"
},
{
"name": "CVE-2026-31625",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31625"
},
{
"name": "CVE-2026-43051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43051"
},
{
"name": "CVE-2026-31759",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31759"
},
{
"name": "CVE-2026-52992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52992"
},
{
"name": "CVE-2023-45896",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45896"
},
{
"name": "CVE-2026-23370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23370"
},
{
"name": "CVE-2026-53112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53112"
},
{
"name": "CVE-2026-46206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46206"
},
{
"name": "CVE-2026-23108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23108"
},
{
"name": "CVE-2025-71180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71180"
},
{
"name": "CVE-2026-43246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43246"
},
{
"name": "CVE-2026-53086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53086"
},
{
"name": "CVE-2026-31781",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31781"
},
{
"name": "CVE-2026-43449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43449"
},
{
"name": "CVE-2026-45948",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45948"
},
{
"name": "CVE-2026-43147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43147"
},
{
"name": "CVE-2025-71194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71194"
},
{
"name": "CVE-2026-31523",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31523"
},
{
"name": "CVE-2026-23023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23023"
},
{
"name": "CVE-2026-43459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43459"
},
{
"name": "CVE-2026-31450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31450"
},
{
"name": "CVE-2026-31671",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31671"
},
{
"name": "CVE-2026-31749",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31749"
},
{
"name": "CVE-2026-22999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22999"
},
{
"name": "CVE-2026-46234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46234"
},
{
"name": "CVE-2026-46250",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46250"
},
{
"name": "CVE-2026-43328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43328"
},
{
"name": "CVE-2026-23068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23068"
},
{
"name": "CVE-2026-64018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64018"
},
{
"name": "CVE-2024-41079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41079"
},
{
"name": "CVE-2026-23089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23089"
},
{
"name": "CVE-2026-43024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43024"
},
{
"name": "CVE-2026-46062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46062"
},
{
"name": "CVE-2026-45985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45985"
},
{
"name": "CVE-2026-23071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23071"
},
{
"name": "CVE-2026-43207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43207"
},
{
"name": "CVE-2025-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23141"
},
{
"name": "CVE-2026-23056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23056"
},
{
"name": "CVE-2026-46108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46108"
},
{
"name": "CVE-2026-53060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53060"
},
{
"name": "CVE-2026-31694",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31694"
},
{
"name": "CVE-2026-23352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23352"
},
{
"name": "CVE-2026-53096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53096"
},
{
"name": "CVE-2026-31720",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31720"
},
{
"name": "CVE-2026-31748",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31748"
},
{
"name": "CVE-2026-31699",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31699"
},
{
"name": "CVE-2026-46049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46049"
},
{
"name": "CVE-2026-46285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46285"
},
{
"name": "CVE-2026-43472",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43472"
},
{
"name": "CVE-2026-23367",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23367"
},
{
"name": "CVE-2026-31628",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31628"
},
{
"name": "CVE-2026-43407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43407"
},
{
"name": "CVE-2026-23063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23063"
},
{
"name": "CVE-2026-45899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45899"
},
{
"name": "CVE-2026-31662",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31662"
},
{
"name": "CVE-2026-23073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23073"
},
{
"name": "CVE-2026-23058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23058"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2026-23238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23238"
},
{
"name": "CVE-2025-71182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71182"
},
{
"name": "CVE-2026-43026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43026"
},
{
"name": "CVE-2026-31480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31480"
},
{
"name": "CVE-2026-64055",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64055"
},
{
"name": "CVE-2026-43405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43405"
},
{
"name": "CVE-2026-46070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46070"
},
{
"name": "CVE-2026-23038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23038"
},
{
"name": "CVE-2026-43430",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43430"
},
{
"name": "CVE-2026-45920",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45920"
},
{
"name": "CVE-2026-46150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46150"
},
{
"name": "CVE-2026-22990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22990"
},
{
"name": "CVE-2026-23000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23000"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2026-43184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43184"
},
{
"name": "CVE-2026-45840",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45840"
},
{
"name": "CVE-2026-23026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23026"
},
{
"name": "CVE-2026-46044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46044"
},
{
"name": "CVE-2026-23446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23446"
},
{
"name": "CVE-2026-23128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23128"
},
{
"name": "CVE-2026-46219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46219"
},
{
"name": "CVE-2026-64173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64173"
},
{
"name": "CVE-2026-53043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53043"
},
{
"name": "CVE-2026-43075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43075"
},
{
"name": "CVE-2026-43035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43035"
},
{
"name": "CVE-2025-71190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71190"
},
{
"name": "CVE-2026-23140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23140"
},
{
"name": "CVE-2026-46172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46172"
},
{
"name": "CVE-2026-31627",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31627"
},
{
"name": "CVE-2024-56657",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56657"
},
{
"name": "CVE-2026-31665",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31665"
},
{
"name": "CVE-2026-46161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46161"
},
{
"name": "CVE-2026-23300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23300"
},
{
"name": "CVE-2026-45941",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45941"
},
{
"name": "CVE-2026-23067",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23067"
},
{
"name": "CVE-2026-23107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23107"
},
{
"name": "CVE-2026-43261",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43261"
},
{
"name": "CVE-2026-23444",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23444"
},
{
"name": "CVE-2026-43304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43304"
},
{
"name": "CVE-2026-22978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22978"
},
{
"name": "CVE-2026-43185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43185"
},
{
"name": "CVE-2026-43378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43378"
},
{
"name": "CVE-2026-64115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64115"
},
{
"name": "CVE-2026-45844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45844"
},
{
"name": "CVE-2026-52985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52985"
},
{
"name": "CVE-2026-43158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43158"
},
{
"name": "CVE-2026-31672",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31672"
},
{
"name": "CVE-2026-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23146"
},
{
"name": "CVE-2026-43501",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43501"
},
{
"name": "CVE-2026-53059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53059"
},
{
"name": "CVE-2026-23018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23018"
},
{
"name": "CVE-2026-43093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43093"
},
{
"name": "CVE-2026-31780",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31780"
},
{
"name": "CVE-2026-43342",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43342"
},
{
"name": "CVE-2026-43379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43379"
},
{
"name": "CVE-2026-64164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64164"
},
{
"name": "CVE-2026-23037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23037"
},
{
"name": "CVE-2026-23243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23243"
},
{
"name": "CVE-2026-46266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46266"
},
{
"name": "CVE-2026-31521",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31521"
},
{
"name": "CVE-2026-31626",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31626"
},
{
"name": "CVE-2026-23106",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23106"
},
{
"name": "CVE-2026-23001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23001"
},
{
"name": "CVE-2026-43357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43357"
},
{
"name": "CVE-2026-31634",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31634"
},
{
"name": "CVE-2026-43061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43061"
},
{
"name": "CVE-2026-46018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46018"
},
{
"name": "CVE-2025-71237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71237"
},
{
"name": "CVE-2026-53012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53012"
},
{
"name": "CVE-2026-43453",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43453"
},
{
"name": "CVE-2026-64096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64096"
},
{
"name": "CVE-2026-43032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43032"
},
{
"name": "CVE-2026-43484",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43484"
},
{
"name": "CVE-2026-45954",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45954"
},
{
"name": "CVE-2026-23025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23025"
},
{
"name": "CVE-2026-23362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23362"
},
{
"name": "CVE-2026-23379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23379"
},
{
"name": "CVE-2026-23118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23118"
},
{
"name": "CVE-2026-43076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43076"
},
{
"name": "CVE-2026-45984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45984"
},
{
"name": "CVE-2026-43427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43427"
},
{
"name": "CVE-2022-50116",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50116"
},
{
"name": "CVE-2026-31421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31421"
},
{
"name": "CVE-2026-53069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53069"
},
{
"name": "CVE-2026-23162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23162"
},
{
"name": "CVE-2026-53228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53228"
},
{
"name": "CVE-2026-53073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53073"
},
{
"name": "CVE-2023-53545",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53545"
},
{
"name": "CVE-2026-43365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43365"
},
{
"name": "CVE-2022-50552",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50552"
},
{
"name": "CVE-2026-23381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23381"
},
{
"name": "CVE-2026-31518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31518"
},
{
"name": "CVE-2026-43296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43296"
},
{
"name": "CVE-2026-46046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46046"
},
{
"name": "CVE-2025-68256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68256"
},
{
"name": "CVE-2026-23221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23221"
},
{
"name": "CVE-2026-31686",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31686"
},
{
"name": "CVE-2026-23151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23151"
},
{
"name": "CVE-2026-31660",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31660"
},
{
"name": "CVE-2026-23392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23392"
},
{
"name": "CVE-2026-45916",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45916"
},
{
"name": "CVE-2026-46294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46294"
},
{
"name": "CVE-2026-31728",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31728"
},
{
"name": "CVE-2026-23008",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23008"
},
{
"name": "CVE-2026-23152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23152"
},
{
"name": "CVE-2026-22982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22982"
},
{
"name": "CVE-2026-46290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46290"
},
{
"name": "CVE-2026-64084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64084"
},
{
"name": "CVE-2026-31400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31400"
},
{
"name": "CVE-2026-31512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31512"
},
{
"name": "CVE-2026-43124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43124"
},
{
"name": "CVE-2026-46135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46135"
},
{
"name": "CVE-2026-43141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43141"
},
{
"name": "CVE-2026-31726",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31726"
},
{
"name": "CVE-2026-43225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43225"
},
{
"name": "CVE-2026-43370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43370"
},
{
"name": "CVE-2026-31773",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31773"
},
{
"name": "CVE-2026-43134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43134"
},
{
"name": "CVE-2023-52682",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52682"
},
{
"name": "CVE-2026-23142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23142"
},
{
"name": "CVE-2025-71150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71150"
},
{
"name": "CVE-2026-46167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46167"
},
{
"name": "CVE-2026-31607",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31607"
},
{
"name": "CVE-2026-23242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23242"
},
{
"name": "CVE-2026-53212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53212"
},
{
"name": "CVE-2026-43015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43015"
},
{
"name": "CVE-2026-31509",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31509"
},
{
"name": "CVE-2025-71292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71292"
},
{
"name": "CVE-2026-43066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43066"
},
{
"name": "CVE-2026-43242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43242"
},
{
"name": "CVE-2026-23237",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23237"
},
{
"name": "CVE-2026-31679",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31679"
},
{
"name": "CVE-2026-31636",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31636"
},
{
"name": "CVE-2021-47378",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47378"
},
{
"name": "CVE-2026-45970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45970"
},
{
"name": "CVE-2025-71192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71192"
},
{
"name": "CVE-2023-53596",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53596"
},
{
"name": "CVE-2026-43469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43469"
},
{
"name": "CVE-2026-31716",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31716"
},
{
"name": "CVE-2026-43085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43085"
},
{
"name": "CVE-2026-23121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23121"
},
{
"name": "CVE-2026-31637",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31637"
},
{
"name": "CVE-2026-23051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23051"
},
{
"name": "CVE-2026-23428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23428"
},
{
"name": "CVE-2026-64113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64113"
},
{
"name": "CVE-2026-31590",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31590"
},
{
"name": "CVE-2026-23034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23034"
},
{
"name": "CVE-2026-64103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64103"
},
{
"name": "CVE-2026-22993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22993"
},
{
"name": "CVE-2026-46274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46274"
},
{
"name": "CVE-2025-38192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38192"
},
{
"name": "CVE-2026-43020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43020"
},
{
"name": "CVE-2026-31417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31417"
},
{
"name": "CVE-2025-71236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71236"
},
{
"name": "CVE-2026-43041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43041"
},
{
"name": "CVE-2026-53247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53247"
},
{
"name": "CVE-2026-31761",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31761"
},
{
"name": "CVE-2026-31466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31466"
},
{
"name": "CVE-2026-43313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43313"
},
{
"name": "CVE-2026-53304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53304"
},
{
"name": "CVE-2026-64174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64174"
},
{
"name": "CVE-2025-54518",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54518"
},
{
"name": "CVE-2026-43111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43111"
},
{
"name": "CVE-2024-56584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56584"
},
{
"name": "CVE-2026-23235",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23235"
},
{
"name": "CVE-2026-22985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22985"
},
{
"name": "CVE-2026-23144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23144"
},
{
"name": "CVE-2026-23087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23087"
},
{
"name": "CVE-2026-31414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31414"
},
{
"name": "CVE-2026-64034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64034"
},
{
"name": "CVE-2026-45958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45958"
},
{
"name": "CVE-2025-71185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71185"
},
{
"name": "CVE-2026-43257",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43257"
},
{
"name": "CVE-2026-31778",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31778"
},
{
"name": "CVE-2026-23096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23096"
},
{
"name": "CVE-2026-43291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43291"
},
{
"name": "CVE-2026-53039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53039"
},
{
"name": "CVE-2026-43180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43180"
},
{
"name": "CVE-2026-43196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43196"
},
{
"name": "CVE-2026-23044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23044"
},
{
"name": "CVE-2026-45968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45968"
},
{
"name": "CVE-2026-53004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53004"
},
{
"name": "CVE-2022-49961",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49961"
},
{
"name": "CVE-2026-43040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43040"
},
{
"name": "CVE-2026-43152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43152"
},
{
"name": "CVE-2026-52912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52912"
},
{
"name": "CVE-2026-43287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43287"
},
{
"name": "CVE-2026-31552",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31552"
},
{
"name": "CVE-2026-64218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64218"
},
{
"name": "CVE-2026-23164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23164"
},
{
"name": "CVE-2026-43133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43133"
},
{
"name": "CVE-2026-46006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46006"
},
{
"name": "CVE-2026-43428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43428"
},
{
"name": "CVE-2026-52998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52998"
},
{
"name": "CVE-2026-53011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53011"
},
{
"name": "CVE-2026-52920",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52920"
},
{
"name": "CVE-2026-31532",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31532"
},
{
"name": "CVE-2026-23124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23124"
},
{
"name": "CVE-2026-53001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53001"
},
{
"name": "CVE-2026-23397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23397"
},
{
"name": "CVE-2026-43206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43206"
},
{
"name": "CVE-2026-23452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23452"
},
{
"name": "CVE-2026-43273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43273"
},
{
"name": "CVE-2026-23002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23002"
},
{
"name": "CVE-2026-23474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23474"
},
{
"name": "CVE-2025-71160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71160"
},
{
"name": "CVE-2025-71232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71232"
},
{
"name": "CVE-2026-52911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52911"
},
{
"name": "CVE-2026-43190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43190"
},
{
"name": "CVE-2026-43065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43065"
},
{
"name": "CVE-2026-45885",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45885"
},
{
"name": "CVE-2026-53295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53295"
},
{
"name": "CVE-2026-43182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43182"
},
{
"name": "CVE-2025-71162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71162"
},
{
"name": "CVE-2026-43226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43226"
},
{
"name": "CVE-2026-23075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23075"
},
{
"name": "CVE-2026-23077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23077"
},
{
"name": "CVE-2026-23120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23120"
},
{
"name": "CVE-2026-23336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23336"
},
{
"name": "CVE-2026-45843",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45843"
},
{
"name": "CVE-2026-22996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22996"
},
{
"name": "CVE-2026-46015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46015"
},
{
"name": "CVE-2026-23168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23168"
},
{
"name": "CVE-2026-64219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64219"
},
{
"name": "CVE-2026-31497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31497"
},
{
"name": "CVE-2026-43451",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43451"
},
{
"name": "CVE-2026-23105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23105"
},
{
"name": "CVE-2026-22976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22976"
},
{
"name": "CVE-2026-43406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43406"
},
{
"name": "CVE-2026-31570",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31570"
},
{
"name": "CVE-2026-53215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53215"
},
{
"name": "CVE-2026-23289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23289"
},
{
"name": "CVE-2026-31755",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31755"
},
{
"name": "CVE-2026-64168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64168"
},
{
"name": "CVE-2026-46230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46230"
},
{
"name": "CVE-2026-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23141"
},
{
"name": "CVE-2026-23065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23065"
},
{
"name": "CVE-2025-21739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21739"
},
{
"name": "CVE-2026-23277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23277"
},
{
"name": "CVE-2026-31399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31399"
},
{
"name": "CVE-2026-22986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22986"
},
{
"name": "CVE-2026-31489",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31489"
},
{
"name": "CVE-2026-23086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23086"
},
{
"name": "CVE-2026-53003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53003"
},
{
"name": "CVE-2026-45964",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45964"
},
{
"name": "CVE-2026-46004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46004"
},
{
"name": "CVE-2026-43343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43343"
},
{
"name": "CVE-2026-43289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43289"
},
{
"name": "CVE-2026-31444",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31444"
},
{
"name": "CVE-2026-43187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43187"
},
{
"name": "CVE-2026-46149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46149"
},
{
"name": "CVE-2026-23455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23455"
},
{
"name": "CVE-2025-38006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38006"
},
{
"name": "CVE-2026-64086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64086"
},
{
"name": "CVE-2026-43341",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43341"
},
{
"name": "CVE-2026-45936",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45936"
},
{
"name": "CVE-2026-46205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46205"
},
{
"name": "CVE-2026-53359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53359"
},
{
"name": "CVE-2026-53016",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53016"
},
{
"name": "CVE-2026-45978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45978"
},
{
"name": "CVE-2026-43159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43159"
},
{
"name": "CVE-2026-23335",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23335"
},
{
"name": "CVE-2026-52986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52986"
},
{
"name": "CVE-2026-31551",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31551"
},
{
"name": "CVE-2026-53077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53077"
},
{
"name": "CVE-2026-31495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31495"
},
{
"name": "CVE-2026-46132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46132"
},
{
"name": "CVE-2026-23156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23156"
},
{
"name": "CVE-2026-23158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23158"
},
{
"name": "CVE-2025-71193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71193"
},
{
"name": "CVE-2026-23095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23095"
},
{
"name": "CVE-2026-46177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46177"
},
{
"name": "CVE-2026-43110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43110"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"name": "CVE-2026-23062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23062"
},
{
"name": "CVE-2026-31507",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31507"
},
{
"name": "CVE-2026-53306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53306"
},
{
"name": "CVE-2026-23266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23266"
},
{
"name": "CVE-2026-43149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43149"
},
{
"name": "CVE-2026-53277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53277"
},
{
"name": "CVE-2026-64587",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64587"
},
{
"name": "CVE-2026-23160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23160"
},
{
"name": "CVE-2026-31762",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31762"
},
{
"name": "CVE-2026-43236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43236"
},
{
"name": "CVE-2026-43071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43071"
},
{
"name": "CVE-2026-31788",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31788"
},
{
"name": "CVE-2026-31411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31411"
},
{
"name": "CVE-2026-31428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31428"
},
{
"name": "CVE-2026-23420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23420"
},
{
"name": "CVE-2026-23388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23388"
},
{
"name": "CVE-2026-53045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53045"
},
{
"name": "CVE-2025-39748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39748"
},
{
"name": "CVE-2026-43098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43098"
},
{
"name": "CVE-2026-43277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43277"
},
{
"name": "CVE-2026-43386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43386"
},
{
"name": "CVE-2026-47333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47333"
},
{
"name": "CVE-2025-71266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71266"
},
{
"name": "CVE-2026-43089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43089"
},
{
"name": "CVE-2026-43037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43037"
},
{
"name": "CVE-2026-23070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23070"
},
{
"name": "CVE-2026-23241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23241"
},
{
"name": "CVE-2026-31596",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31596"
},
{
"name": "CVE-2026-43266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43266"
},
{
"name": "CVE-2026-23033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23033"
},
{
"name": "CVE-2026-31676",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31676"
},
{
"name": "CVE-2026-22977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22977"
},
{
"name": "CVE-2026-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23145"
},
{
"name": "CVE-2026-43186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43186"
},
{
"name": "CVE-2026-43112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43112"
},
{
"name": "CVE-2026-43083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43083"
},
{
"name": "CVE-2026-23442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23442"
},
{
"name": "CVE-2026-31476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31476"
},
{
"name": "CVE-2026-31603",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31603"
},
{
"name": "CVE-2026-23104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23104"
},
{
"name": "CVE-2026-46107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46107"
},
{
"name": "CVE-2026-46047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46047"
},
{
"name": "CVE-2026-46273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46273"
},
{
"name": "CVE-2026-23458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23458"
},
{
"name": "CVE-2026-23003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23003"
},
{
"name": "CVE-2026-43502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43502"
},
{
"name": "CVE-2026-31649",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31649"
},
{
"name": "CVE-2026-53379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53379"
},
{
"name": "CVE-2026-31674",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31674"
},
{
"name": "CVE-2026-31393",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31393"
},
{
"name": "CVE-2026-43420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43420"
},
{
"name": "CVE-2026-23076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23076"
},
{
"name": "CVE-2026-45994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45994"
},
{
"name": "CVE-2026-31577",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31577"
},
{
"name": "CVE-2026-43233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43233"
},
{
"name": "CVE-2026-43027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43027"
},
{
"name": "CVE-2026-46267",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46267"
},
{
"name": "CVE-2026-46249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46249"
},
{
"name": "CVE-2026-45904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45904"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2026-46163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46163"
},
{
"name": "CVE-2025-71158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71158"
},
{
"name": "CVE-2022-49803",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49803"
},
{
"name": "CVE-2026-46270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46270"
},
{
"name": "CVE-2026-31576",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31576"
},
{
"name": "CVE-2026-64032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64032"
},
{
"name": "CVE-2026-45838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45838"
},
{
"name": "CVE-2026-43295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43295"
},
{
"name": "CVE-2026-23339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23339"
},
{
"name": "CVE-2026-23171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23171"
},
{
"name": "CVE-2026-23010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23010"
},
{
"name": "CVE-2026-43148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43148"
},
{
"name": "CVE-2026-45935",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45935"
},
{
"name": "CVE-2026-53023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53023"
},
{
"name": "CVE-2026-31433",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31433"
},
{
"name": "CVE-2026-43497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43497"
},
{
"name": "CVE-2026-43312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43312"
},
{
"name": "CVE-2026-45924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45924"
},
{
"name": "CVE-2026-46077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46077"
},
{
"name": "CVE-2026-45891",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45891"
},
{
"name": "CVE-2026-64056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64056"
},
{
"name": "CVE-2026-52962",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52962"
},
{
"name": "CVE-2026-63860",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63860"
},
{
"name": "CVE-2026-53093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53093"
},
{
"name": "CVE-2026-31589",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31589"
},
{
"name": "CVE-2026-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23084"
},
{
"name": "CVE-2026-22979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22979"
},
{
"name": "CVE-2026-64033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64033"
},
{
"name": "CVE-2026-23460",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23460"
},
{
"name": "CVE-2026-46187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46187"
},
{
"name": "CVE-2026-43281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43281"
},
{
"name": "CVE-2026-23011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23011"
},
{
"name": "CVE-2026-23015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23015"
},
{
"name": "CVE-2025-71161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71161"
},
{
"name": "CVE-2026-46168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46168"
},
{
"name": "CVE-2026-53075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53075"
},
{
"name": "CVE-2026-53246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53246"
},
{
"name": "CVE-2026-31540",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31540"
},
{
"name": "CVE-2026-45986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45986"
},
{
"name": "CVE-2026-23395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23395"
},
{
"name": "CVE-2026-45987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45987"
},
{
"name": "CVE-2026-31651",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31651"
},
{
"name": "CVE-2026-23110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23110"
},
{
"name": "CVE-2026-23100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23100"
},
{
"name": "CVE-2025-21863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21863"
},
{
"name": "CVE-2026-31657",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31657"
},
{
"name": "CVE-2026-43302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43302"
},
{
"name": "CVE-2026-31747",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31747"
},
{
"name": "CVE-2026-31455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31455"
},
{
"name": "CVE-2026-43316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43316"
},
{
"name": "CVE-2026-31624",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31624"
},
{
"name": "CVE-2026-46050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46050"
},
{
"name": "CVE-2025-71233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71233"
},
{
"name": "CVE-2026-43340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43340"
},
{
"name": "CVE-2026-23148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23148"
},
{
"name": "CVE-2026-46009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46009"
},
{
"name": "CVE-2026-31585",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31585"
},
{
"name": "CVE-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2026-53151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53151"
},
{
"name": "CVE-2026-23031",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23031"
},
{
"name": "CVE-2025-37786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37786"
},
{
"name": "CVE-2026-23102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23102"
},
{
"name": "CVE-2026-22998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22998"
},
{
"name": "CVE-2026-23050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23050"
},
{
"name": "CVE-2026-23161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23161"
},
{
"name": "CVE-2026-64153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64153"
},
{
"name": "CVE-2026-23291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23291"
},
{
"name": "CVE-2026-53037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53037"
},
{
"name": "CVE-2026-53072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53072"
},
{
"name": "CVE-2026-52921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52921"
},
{
"name": "CVE-2026-46023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46023"
},
{
"name": "CVE-2026-53068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53068"
},
{
"name": "CVE-2026-46304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46304"
},
{
"name": "CVE-2026-43156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43156"
},
{
"name": "CVE-2025-68239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68239"
},
{
"name": "CVE-2026-43194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43194"
},
{
"name": "CVE-2026-23382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23382"
},
{
"name": "CVE-2026-31633",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31633"
},
{
"name": "CVE-2026-43473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43473"
},
{
"name": "CVE-2026-43230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43230"
},
{
"name": "CVE-2026-43209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43209"
},
{
"name": "CVE-2026-31446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31446"
},
{
"name": "CVE-2026-46275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46275"
},
{
"name": "CVE-2026-23024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23024"
},
{
"name": "CVE-2026-23113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23113"
},
{
"name": "CVE-2026-45902",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45902"
},
{
"name": "CVE-2026-23157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23157"
},
{
"name": "CVE-2026-31464",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31464"
},
{
"name": "CVE-2026-46033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46033"
},
{
"name": "CVE-2026-64087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64087"
},
{
"name": "CVE-2025-71274",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71274"
},
{
"name": "CVE-2026-46212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46212"
},
{
"name": "CVE-2026-45834",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45834"
},
{
"name": "CVE-2026-43171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43171"
},
{
"name": "CVE-2026-23097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23097"
},
{
"name": "CVE-2026-31695",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31695"
},
{
"name": "CVE-2026-31630",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31630"
},
{
"name": "CVE-2025-71198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71198"
},
{
"name": "CVE-2026-43333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43333"
},
{
"name": "CVE-2026-23036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23036"
},
{
"name": "CVE-2026-43105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43105"
},
{
"name": "CVE-2026-23312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23312"
},
{
"name": "CVE-2026-31508",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31508"
},
{
"name": "CVE-2026-23052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23052"
},
{
"name": "CVE-2026-64185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64185"
},
{
"name": "CVE-2026-23021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23021"
},
{
"name": "CVE-2026-23365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23365"
},
{
"name": "CVE-2025-40323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40323"
},
{
"name": "CVE-2026-43275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43275"
},
{
"name": "CVE-2026-45983",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45983"
},
{
"name": "CVE-2026-46123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46123"
},
{
"name": "CVE-2026-43329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43329"
},
{
"name": "CVE-2026-31424",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31424"
},
{
"name": "CVE-2026-23093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23093"
},
{
"name": "CVE-2026-23356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23356"
},
{
"name": "CVE-2026-45875",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45875"
},
{
"name": "CVE-2026-23307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23307"
},
{
"name": "CVE-2026-52969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52969"
},
{
"name": "CVE-2026-46098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46098"
},
{
"name": "CVE-2025-71183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71183"
},
{
"name": "CVE-2026-43038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43038"
},
{
"name": "CVE-2026-53062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53062"
},
{
"name": "CVE-2026-64114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64114"
},
{
"name": "CVE-2026-45974",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45974"
},
{
"name": "CVE-2026-45965",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45965"
},
{
"name": "CVE-2026-43218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43218"
},
{
"name": "CVE-2026-23053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23053"
},
{
"name": "CVE-2026-43363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43363"
},
{
"name": "CVE-2026-64088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64088"
},
{
"name": "CVE-2026-45915",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45915"
},
{
"name": "CVE-2026-31454",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31454"
},
{
"name": "CVE-2024-35865",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35865"
},
{
"name": "CVE-2025-71184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71184"
},
{
"name": "CVE-2025-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38659"
},
{
"name": "CVE-2026-43130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43130"
},
{
"name": "CVE-2026-31452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31452"
},
{
"name": "CVE-2026-31501",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31501"
},
{
"name": "CVE-2026-46053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46053"
},
{
"name": "CVE-2026-53369",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53369"
},
{
"name": "CVE-2026-31407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31407"
},
{
"name": "CVE-2026-23398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23398"
},
{
"name": "CVE-2025-68263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68263"
},
{
"name": "CVE-2026-53082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53082"
},
{
"name": "CVE-2026-52926",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52926"
},
{
"name": "CVE-2026-31602",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31602"
},
{
"name": "CVE-2026-31425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31425"
},
{
"name": "CVE-2026-46238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46238"
},
{
"name": "CVE-2026-64135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64135"
},
{
"name": "CVE-2026-46051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46051"
},
{
"name": "CVE-2025-71238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71238"
},
{
"name": "CVE-2026-45890",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45890"
},
{
"name": "CVE-2026-43255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43255"
},
{
"name": "CVE-2026-53074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53074"
},
{
"name": "CVE-2026-45839",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45839"
},
{
"name": "CVE-2026-43283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43283"
},
{
"name": "CVE-2026-46088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46088"
},
{
"name": "CVE-2026-23147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23147"
},
{
"name": "CVE-2026-52982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52982"
},
{
"name": "CVE-2026-31629",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31629"
},
{
"name": "CVE-2026-23080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23080"
},
{
"name": "CVE-2026-46102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46102"
},
{
"name": "CVE-2026-43050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43050"
},
{
"name": "CVE-2026-53022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53022"
},
{
"name": "CVE-2026-45969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45969"
},
{
"name": "CVE-2026-43203",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43203"
},
{
"name": "CVE-2026-23154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23154"
},
{
"name": "CVE-2026-31673",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31673"
},
{
"name": "CVE-2026-31667",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31667"
}
],
"initial_release_date": "2026-08-28T00:00:00",
"last_revision_date": "2026-08-28T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1093",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-08-28T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8666-3",
"url": "https://ubuntu.com/security/notices/USN-8666-3"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8643-3",
"url": "https://ubuntu.com/security/notices/USN-8643-3"
},
{
"published_at": "2026-08-26",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8659-4",
"url": "https://ubuntu.com/security/notices/USN-8659-4"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu LSN-0121-1",
"url": "https://ubuntu.com/security/notices/LSN-0121-1"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8669-1",
"url": "https://ubuntu.com/security/notices/USN-8669-1"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8667-1",
"url": "https://ubuntu.com/security/notices/USN-8667-1"
},
{
"published_at": "2026-08-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8643-4",
"url": "https://ubuntu.com/security/notices/USN-8643-4"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8662-2",
"url": "https://ubuntu.com/security/notices/USN-8662-2"
},
{
"published_at": "2026-08-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8666-2",
"url": "https://ubuntu.com/security/notices/USN-8666-2"
},
{
"published_at": "2026-08-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8659-3",
"url": "https://ubuntu.com/security/notices/USN-8659-3"
},
{
"published_at": "2026-08-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8630-5",
"url": "https://ubuntu.com/security/notices/USN-8630-5"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8658-4",
"url": "https://ubuntu.com/security/notices/USN-8658-4"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8668-1",
"url": "https://ubuntu.com/security/notices/USN-8668-1"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8661-2",
"url": "https://ubuntu.com/security/notices/USN-8661-2"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8659-2",
"url": "https://ubuntu.com/security/notices/USN-8659-2"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8658-2",
"url": "https://ubuntu.com/security/notices/USN-8658-2"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8644-3",
"url": "https://ubuntu.com/security/notices/USN-8644-3"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8643-5",
"url": "https://ubuntu.com/security/notices/USN-8643-5"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8661-3",
"url": "https://ubuntu.com/security/notices/USN-8661-3"
},
{
"published_at": "2026-08-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8658-3",
"url": "https://ubuntu.com/security/notices/USN-8658-3"
}
]
}
FKIE_CVE-2026-31393
Vulnerability from fkie_nvd - Published: 2026-04-03 16:16 - Updated: 2026-07-24 22:10| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/187e6fe939295be36063a1d91f8bebee04399a8c | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/3b646516cba2ebc4b51a72954903326e7c1e443f | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/5229e7d15771eac2b5886bfb1f976aea0c1eec14 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/807bd1258453c4c83f6ae9dbc1e7b44860ff40d0 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/9aeacde4da0f02d42fd968fd32f245828b230171 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/db2872d054e467810078e2b9f440a5b326a601b2 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/dd815e6e3918dc75a49aaabac36e4f024d675101 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/e7ff754e339e3d5ce29aa9f95352d0186df8fbd9 | Patch |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/bluetooth/l2cap_core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "187e6fe939295be36063a1d91f8bebee04399a8c",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "5229e7d15771eac2b5886bfb1f976aea0c1eec14",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "3b646516cba2ebc4b51a72954903326e7c1e443f",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "807bd1258453c4c83f6ae9dbc1e7b44860ff40d0",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "9aeacde4da0f02d42fd968fd32f245828b230171",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "e7ff754e339e3d5ce29aa9f95352d0186df8fbd9",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "db2872d054e467810078e2b9f440a5b326a601b2",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
},
{
"lessThan": "dd815e6e3918dc75a49aaabac36e4f024d675101",
"status": "affected",
"version": "4e8402a3f884427f9233ba436459c158d1f2e114",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/bluetooth/l2cap_core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.24"
},
{
"lessThan": "2.6.24",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.253",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.203",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.167",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.130",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.78",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.20",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "23F88A56-E27D-46A7-B32C-65333C046B72",
"versionEndExcluding": "5.10.253",
"versionStartIncluding": "2.6.24",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "20DDB3E9-AABF-4107-ADB0-5362AA067045",
"versionEndExcluding": "5.15.203",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "2EDC6BAF-B710-4E26-B6AA-D68922EE7B43",
"versionEndExcluding": "6.1.167",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C57BB918-DF28-46B3-94F7-144176841267",
"versionEndExcluding": "6.6.130",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "28D591F5-B196-4CC9-905C-DC80F116E7A8",
"versionEndExcluding": "6.12.78",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E5571059-6552-48E7-9BEF-3E358C387171",
"versionEndExcluding": "6.18.20",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "96D34333-38BE-4414-9E79-6EB764329581",
"versionEndExcluding": "6.19.10",
"versionStartIncluding": "6.19",
"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
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access\n\nl2cap_information_rsp() checks that cmd_len covers the fixed\nl2cap_info_rsp header (type + result, 4 bytes) but then reads\nrsp-\u003edata without verifying that the payload is present:\n\n - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp-\u003edata), which reads\n 4 bytes past the header (needs cmd_len \u003e= 8).\n\n - L2CAP_IT_FIXED_CHAN reads rsp-\u003edata[0], 1 byte past the header\n (needs cmd_len \u003e= 5).\n\nA truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an\nout-of-bounds read of adjacent skb data.\n\nGuard each data access with the required payload length check. If the\npayload is too short, skip the read and let the state machine complete\nwith safe defaults (feat_mask and remote_fixed_chan remain zero from\nkzalloc), so the info timer cleanup and l2cap_conn_start() still run\nand the connection is not stalled."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nBluetooth: L2CAP: Validar la longitud de la carga \u00fatil de L2CAP_INFO_RSP antes del acceso\n\nl2cap_information_rsp() comprueba que cmd_len cubre la cabecera fija de l2cap_info_rsp (tipo + resultado, 4 bytes) pero luego lee rsp -\u003e data sin verificar que la carga \u00fatil est\u00e9 presente:\n\n - L2CAP_IT_FEAT_MASK llama a get_unaligned_le32(rsp -\u003e data), que lee 4 bytes despu\u00e9s de la cabecera (necesita cmd_len \u003e= 8).\n\n - L2CAP_IT_FIXED_CHAN lee rsp -\u003e data[0], 1 byte despu\u00e9s de la cabecera (necesita cmd_len \u003e= 5).\n\nUn L2CAP_INFO_RSP truncado con result == L2CAP_IR_SUCCESS desencadena una lectura fuera de l\u00edmites de datos skb adyacentes.\n\nProteger cada acceso a datos con la comprobaci\u00f3n de longitud de carga \u00fatil requerida. Si la carga \u00fatil es demasiado corta, omitir la lectura y permitir que la m\u00e1quina de estados se complete con valores predeterminados seguros (feat_mask y remote_fixed_chan permanecen en cero desde kzalloc), para que la limpieza del temporizador de informaci\u00f3n y l2cap_conn_start() sigan ejecut\u00e1ndose y la conexi\u00f3n no se estanque."
}
],
"id": "CVE-2026-31393",
"lastModified": "2026-07-24T22:10:00.140",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 2.8,
"impactScore": 5.2,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2026-04-03T16:16:37.420",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/187e6fe939295be36063a1d91f8bebee04399a8c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3b646516cba2ebc4b51a72954903326e7c1e443f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5229e7d15771eac2b5886bfb1f976aea0c1eec14"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/807bd1258453c4c83f6ae9dbc1e7b44860ff40d0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/9aeacde4da0f02d42fd968fd32f245828b230171"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/db2872d054e467810078e2b9f440a5b326a601b2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/dd815e6e3918dc75a49aaabac36e4f024d675101"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e7ff754e339e3d5ce29aa9f95352d0186df8fbd9"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-CPMG-R9CR-Q8PJ
Vulnerability from github – Published: 2026-04-03 18:31 – Updated: 2026-04-27 15:30In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access
l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present:
-
L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8).
-
L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5).
A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data.
Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.
{
"affected": [],
"aliases": [
"CVE-2026-31393"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-03T16:16:37Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access\n\nl2cap_information_rsp() checks that cmd_len covers the fixed\nl2cap_info_rsp header (type + result, 4 bytes) but then reads\nrsp-\u003edata without verifying that the payload is present:\n\n - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp-\u003edata), which reads\n 4 bytes past the header (needs cmd_len \u003e= 8).\n\n - L2CAP_IT_FIXED_CHAN reads rsp-\u003edata[0], 1 byte past the header\n (needs cmd_len \u003e= 5).\n\nA truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an\nout-of-bounds read of adjacent skb data.\n\nGuard each data access with the required payload length check. If the\npayload is too short, skip the read and let the state machine complete\nwith safe defaults (feat_mask and remote_fixed_chan remain zero from\nkzalloc), so the info timer cleanup and l2cap_conn_start() still run\nand the connection is not stalled.",
"id": "GHSA-cpmg-r9cr-q8pj",
"modified": "2026-04-27T15:30:31Z",
"published": "2026-04-03T18:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31393"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/187e6fe939295be36063a1d91f8bebee04399a8c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b646516cba2ebc4b51a72954903326e7c1e443f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5229e7d15771eac2b5886bfb1f976aea0c1eec14"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/807bd1258453c4c83f6ae9dbc1e7b44860ff40d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9aeacde4da0f02d42fd968fd32f245828b230171"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/db2872d054e467810078e2b9f440a5b326a601b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd815e6e3918dc75a49aaabac36e4f024d675101"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e7ff754e339e3d5ce29aa9f95352d0186df8fbd9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
OESA-2026-1946 (CVE-2025-68291)
Vulnerability from osv_openeuler – Published: 2026-04-17 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in mptcp_do_fastclose().
syzbot reported divide-by-zero in __tcp_select_window() by MPTCP socket. [0]
We had a similar issue for the bare TCP and fixed in commit 499350a5a6e7 ("tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0").
Let's apply the same fix to mptcp_do_fastclose().
[0]: Oops: divide error: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 RIP: 0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336 Code: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 <f7> 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00 RSP: 0018:ffffc90003017640 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028 R10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0 Call Trace: <TASK> tcp_select_window net/ipv4/tcp_output.c:281 [inline] __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568 tcp_transmit_skb net/ipv4/tcp_output.c:1649 [inline] tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836 mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793 mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253 mptcp_sendmsg_fastopen+0x2f8/0x580 net/mptcp/protocol.c:1776 mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe5/0x270 net/socket.c:742 __sys_sendto+0x3bd/0x520 net/socket.c:2244 __do_sys_sendto net/socket.c:2251 [inline] __se_sys_sendto net/socket.c:2247 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2247 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f66e998f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006 </TASK>(CVE-2025-68291)
In the Linux kernel, the following vulnerability has been resolved:
tcp: secure_seq: add back ports to TS offset
This reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")
tcp_tw_recycle went away in 2017.
Zhouyan Deng reported off-path TCP source port leakage via SYN cookie side-channel that can be fixed in multiple ways.
One of them is to bring back TCP ports in TS offset randomization.
As a bonus, we perform a single siphash() computation to provide both an ISN and a TS offset.(CVE-2026-23247)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: validate DFA start states are in bounds in unpack_pdb
Start states are read from untrusted data and used as indexes into the DFA state tables. The aa_dfa_next() function call in unpack_pdb() will access dfa->tables[YYTD_ID_BASE][start], and if the start state exceeds the number of states in the DFA, this results in an out-of-bound read.
================================================================== BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360 Read of size 4 at addr ffff88811956fb90 by task su/1097 ...
Reject policies with out-of-bounds start states during unpacking to prevent the issue.(CVE-2026-23269)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix memory leak in ice_set_ringparam()
In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings.
Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails.
Compile tested only. Issue found using a prototype static analysis tool and code review.(CVE-2026-23389)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix race condition during IPSec ESN update
In IPSec full offload mode, the device reports an ESN (Extended Sequence Number) wrap event to the driver. The driver validates this event by querying the IPSec ASO and checking that the esn_event_arm field is 0x0, which indicates an event has occurred. After handling the event, the driver must re-arm the context by setting esn_event_arm back to 0x1.
A race condition exists in this handling path. After validating the event, the driver calls mlx5_accel_esp_modify_xfrm() to update the kernel's xfrm state. This function temporarily releases and re-acquires the xfrm state lock.
So, need to acknowledge the event first by setting esn_event_arm to 0x1. This prevents the driver from reprocessing the same ESN update if the hardware sends events for other reason. Since the next ESN update only occurs after nearly 2^31 packets are received, there's no risk of missing an update, as it will happen long after this handling has finished.
Processing the event twice causes the ESN high-order bits (esn_msb) to be incremented incorrectly. The driver then programs the hardware with this invalid ESN state, which leads to anti-replay failures and a complete halt of IPSec traffic.
Fix this by re-arming the ESN event immediately after it is validated, before calling mlx5_accel_esp_modify_xfrm(). This ensures that any spurious, duplicate events are correctly ignored, closing the race window.(CVE-2026-23440)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent concurrent access to IPSec ASO context
The query or updating IPSec offload object is through Access ASO WQE. The driver uses a single mlx5e_ipsec_aso struct for each PF, which contains a shared DMA-mapped context for all ASO operations.
A race condition exists because the ASO spinlock is released before the hardware has finished processing WQE. If a second operation is initiated immediately after, it overwrites the shared context in the DMA area.
When the first operation's completion is processed later, it reads this corrupted context, leading to unexpected behavior and incorrect results.
This commit fixes the race by introducing a private context within each IPSec offload object. The shared ASO context is now copied to this private context while the ASO spinlock is held. Subsequent processing uses this saved, per-object context, ensuring its integrity is maintained.(CVE-2026-23441)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure
ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do.
Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free.
Document the skb ownership guarantee in the function's kdoc.(CVE-2026-23444)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user
After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del"), l2cap_conn_del() uses conn->lock to protect access to conn->users. However, l2cap_register_user() and l2cap_unregister_user() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2cap_conn_del().
This can lead to use-after-free and list corruption bugs, as reported by syzbot.
Fix this by changing l2cap_register_user() and l2cap_unregister_user() to use conn->lock instead of hci_dev_lock(), ensuring consistent locking for the l2cap_conn structure.(CVE-2026-23461)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access
l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present:
-
L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8).
-
L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5).
A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data.
Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.(CVE-2026-31393)
In the Linux kernel, the following vulnerability has been resolved:
nvdimm/bus: Fix potential use after free in asynchronous initialization
Dingisoul with KASAN reports a use after free if device_add() fails in nd_async_device_register().
Commit b6eae0f61db2 ("libnvdimm: Hold reference on parent while scheduling async init") correctly added a reference on the parent device to be held until asynchronous initialization was complete. However, if device_add() results in an allocation failure the ref count of the device drops to 0 prior to the parent pointer being accessed. Thus resulting in use after free.
The bug bot AI correctly identified the fix. Save a reference to the parent pointer to be used to drop the parent reference regardless of the outcome of device_add().(CVE-2026-31399)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-net: fix OOB access in ULE extension header tables
The ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables in handle_one_ule_extension() are declared with 255 elements (valid indices 0-254), but the index htype is derived from network-controlled data as (ule_sndu_type & 0x00FF), giving a range of 0-255. When htype equals 255, an out-of-bounds read occurs on the function pointer table, and the OOB value may be called as a function pointer.
Add a bounds check on htype against the array size before either table is accessed. Out-of-range values now cause the SNDU to be discarded.(CVE-2026-31405)
In the Linux kernel, the Bluetooth SCO module's sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"kernel-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"kernel-source-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"perf-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"python3-perf-6.6.0-145.0.3.131.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.3.131.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.0.3.131.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"kernel-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"kernel-source-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"perf-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"python3-perf-6.6.0-145.0.3.131.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.3.131.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-145.0.3.131.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: Initialise rcv_mss before calling tcp_send_active_reset() in mptcp_do_fastclose().\n\nsyzbot reported divide-by-zero in __tcp_select_window() by\nMPTCP socket. [0]\n\nWe had a similar issue for the bare TCP and fixed in commit\n499350a5a6e7 (\u0026quot;tcp: initialize rcv_mss to TCP_MIN_MSS instead\nof 0\u0026quot;).\n\nLet\u0026apos;s apply the same fix to mptcp_do_fastclose().\n\n[0]:\nOops: divide error: 0000 [#1] SMP KASAN PTI\nCPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nRIP: 0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336\nCode: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 \u0026lt;f7\u0026gt; 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00\nRSP: 0018:ffffc90003017640 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028\nR10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS: 000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tcp_select_window net/ipv4/tcp_output.c:281 [inline]\n __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568\n tcp_transmit_skb net/ipv4/tcp_output.c:1649 [inline]\n tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836\n mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793\n mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253\n mptcp_sendmsg_fastopen+0x2f8/0x580 net/mptcp/protocol.c:1776\n mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0xe5/0x270 net/socket.c:742\n __sys_sendto+0x3bd/0x520 net/socket.c:2244\n __do_sys_sendto net/socket.c:2251 [inline]\n __se_sys_sendto net/socket.c:2247 [inline]\n __x64_sys_sendto+0xde/0x100 net/socket.c:2247\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f66e998f749\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001\nR13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006\n \u0026lt;/TASK\u0026gt;(CVE-2025-68291)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: secure_seq: add back ports to TS offset\n\nThis reverts 28ee1b746f49 (\u0026quot;secure_seq: downgrade to per-host timestamp offsets\u0026quot;)\n\ntcp_tw_recycle went away in 2017.\n\nZhouyan Deng reported off-path TCP source port leakage via\nSYN cookie side-channel that can be fixed in multiple ways.\n\nOne of them is to bring back TCP ports in TS offset randomization.\n\nAs a bonus, we perform a single siphash() computation\nto provide both an ISN and a TS offset.(CVE-2026-23247)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: validate DFA start states are in bounds in unpack_pdb\n\nStart states are read from untrusted data and used as indexes into the\nDFA state tables. The aa_dfa_next() function call in unpack_pdb() will\naccess dfa-\u0026gt;tables[YYTD_ID_BASE][start], and if the start state exceeds\nthe number of states in the DFA, this results in an out-of-bound read.\n\n==================================================================\n BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360\n Read of size 4 at addr ffff88811956fb90 by task su/1097\n ...\n\nReject policies with out-of-bounds start states during unpacking\nto prevent the issue.(CVE-2026-23269)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix memory leak in ice_set_ringparam()\n\nIn ice_set_ringparam, tx_rings and xdp_rings are allocated before\nrx_rings. If the allocation of rx_rings fails, the code jumps to\nthe done label leaking both tx_rings and xdp_rings. Furthermore, if\nthe setup of an individual Rx ring fails during the loop, the code jumps\nto the free_tx label which releases tx_rings but leaks xdp_rings.\n\nFix this by introducing a free_xdp label and updating the error paths to\nensure both xdp_rings and tx_rings are properly freed if rx_rings\nallocation or setup fails.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.(CVE-2026-23389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix race condition during IPSec ESN update\n\nIn IPSec full offload mode, the device reports an ESN (Extended\nSequence Number) wrap event to the driver. The driver validates this\nevent by querying the IPSec ASO and checking that the esn_event_arm\nfield is 0x0, which indicates an event has occurred. After handling\nthe event, the driver must re-arm the context by setting esn_event_arm\nback to 0x1.\n\nA race condition exists in this handling path. After validating the\nevent, the driver calls mlx5_accel_esp_modify_xfrm() to update the\nkernel\u0026apos;s xfrm state. This function temporarily releases and\nre-acquires the xfrm state lock.\n\nSo, need to acknowledge the event first by setting esn_event_arm to\n0x1. This prevents the driver from reprocessing the same ESN update if\nthe hardware sends events for other reason. Since the next ESN update\nonly occurs after nearly 2^31 packets are received, there\u0026apos;s no risk of\nmissing an update, as it will happen long after this handling has\nfinished.\n\nProcessing the event twice causes the ESN high-order bits (esn_msb) to\nbe incremented incorrectly. The driver then programs the hardware with\nthis invalid ESN state, which leads to anti-replay failures and a\ncomplete halt of IPSec traffic.\n\nFix this by re-arming the ESN event immediately after it is validated,\nbefore calling mlx5_accel_esp_modify_xfrm(). This ensures that any\nspurious, duplicate events are correctly ignored, closing the race\nwindow.(CVE-2026-23440)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Prevent concurrent access to IPSec ASO context\n\nThe query or updating IPSec offload object is through Access ASO WQE.\nThe driver uses a single mlx5e_ipsec_aso struct for each PF, which\ncontains a shared DMA-mapped context for all ASO operations.\n\nA race condition exists because the ASO spinlock is released before\nthe hardware has finished processing WQE. If a second operation is\ninitiated immediately after, it overwrites the shared context in the\nDMA area.\n\nWhen the first operation\u0026apos;s completion is processed later, it reads\nthis corrupted context, leading to unexpected behavior and incorrect\nresults.\n\nThis commit fixes the race by introducing a private context within\neach IPSec offload object. The shared ASO context is now copied to\nthis private context while the ASO spinlock is held. Subsequent\nprocessing uses this saved, per-object context, ensuring its integrity\nis maintained.(CVE-2026-23441)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure\n\nieee80211_tx_prepare_skb() has three error paths, but only two of them\nfree the skb. The first error path (ieee80211_tx_prepare() returning\nTX_DROP) does not free it, while invoke_tx_handlers() failure and the\nfragmentation check both do.\n\nAdd kfree_skb() to the first error path so all three are consistent,\nand remove the now-redundant frees in callers (ath9k, mt76,\nmac80211_hwsim) to avoid double-free.\n\nDocument the skb ownership guarantee in the function\u0026apos;s kdoc.(CVE-2026-23444)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user\n\nAfter commit ab4eedb790ca (\u0026quot;Bluetooth: L2CAP: Fix corrupted list in\nhci_chan_del\u0026quot;), l2cap_conn_del() uses conn-\u0026gt;lock to protect access to\nconn-\u0026gt;users. However, l2cap_register_user() and l2cap_unregister_user()\ndon\u0026apos;t use conn-\u0026gt;lock, creating a race condition where these functions can\naccess conn-\u0026gt;users and conn-\u0026gt;hchan concurrently with l2cap_conn_del().\n\nThis can lead to use-after-free and list corruption bugs, as reported\nby syzbot.\n\nFix this by changing l2cap_register_user() and l2cap_unregister_user()\nto use conn-\u0026gt;lock instead of hci_dev_lock(), ensuring consistent locking\nfor the l2cap_conn structure.(CVE-2026-23461)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access\n\nl2cap_information_rsp() checks that cmd_len covers the fixed\nl2cap_info_rsp header (type + result, 4 bytes) but then reads\nrsp-\u0026gt;data without verifying that the payload is present:\n\n - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp-\u0026gt;data), which reads\n 4 bytes past the header (needs cmd_len \u0026gt;= 8).\n\n - L2CAP_IT_FIXED_CHAN reads rsp-\u0026gt;data[0], 1 byte past the header\n (needs cmd_len \u0026gt;= 5).\n\nA truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an\nout-of-bounds read of adjacent skb data.\n\nGuard each data access with the required payload length check. If the\npayload is too short, skip the read and let the state machine complete\nwith safe defaults (feat_mask and remote_fixed_chan remain zero from\nkzalloc), so the info timer cleanup and l2cap_conn_start() still run\nand the connection is not stalled.(CVE-2026-31393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvdimm/bus: Fix potential use after free in asynchronous initialization\n\nDingisoul with KASAN reports a use after free if device_add() fails in\nnd_async_device_register().\n\nCommit b6eae0f61db2 (\u0026quot;libnvdimm: Hold reference on parent while\nscheduling async init\u0026quot;) correctly added a reference on the parent device\nto be held until asynchronous initialization was complete. However, if\ndevice_add() results in an allocation failure the ref count of the\ndevice drops to 0 prior to the parent pointer being accessed. Thus\nresulting in use after free.\n\nThe bug bot AI correctly identified the fix. Save a reference to the\nparent pointer to be used to drop the parent reference regardless of the\noutcome of device_add().(CVE-2026-31399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-net: fix OOB access in ULE extension header tables\n\nThe ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables\nin handle_one_ule_extension() are declared with 255 elements (valid\nindices 0-254), but the index htype is derived from network-controlled\ndata as (ule_sndu_type \u0026amp; 0x00FF), giving a range of 0-255. When\nhtype equals 255, an out-of-bounds read occurs on the function pointer\ntable, and the OOB value may be called as a function pointer.\n\nAdd a bounds check on htype against the array size before either table\nis accessed. Out-of-range values now cause the SNDU to be discarded.(CVE-2026-31405)\n\nIn the Linux kernel, the Bluetooth SCO module\u0026apos;s sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn-\u0026gt;sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk-\u0026gt;sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)",
"id": "OESA-2026-1946",
"modified": "2026-08-06T11:10:57Z",
"published": "2026-04-17T11:10:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1946"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68291"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23247"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23389"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23440"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23441"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23444"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23461"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31399"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31405"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31408"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-68291",
"CVE-2026-23247",
"CVE-2026-23269",
"CVE-2026-23389",
"CVE-2026-23440",
"CVE-2026-23441",
"CVE-2026-23444",
"CVE-2026-23461",
"CVE-2026-31393",
"CVE-2026-31399",
"CVE-2026-31405",
"CVE-2026-31408"
]
}
OESA-2026-1947 (CVE-2025-68291)
Vulnerability from osv_openeuler – Published: 2026-04-17 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in mptcp_do_fastclose().
syzbot reported divide-by-zero in __tcp_select_window() by MPTCP socket. [0]
We had a similar issue for the bare TCP and fixed in commit 499350a5a6e7 ("tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0").
Let's apply the same fix to mptcp_do_fastclose().
[0]: Oops: divide error: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 RIP: 0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336 Code: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 <f7> 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00 RSP: 0018:ffffc90003017640 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028 R10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0 Call Trace: <TASK> tcp_select_window net/ipv4/tcp_output.c:281 [inline] __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568 tcp_transmit_skb net/ipv4/tcp_output.c:1649 [inline] tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836 mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793 mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253 mptcp_sendmsg_fastopen+0x2f8/0x580 net/mptcp/protocol.c:1776 mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe5/0x270 net/socket.c:742 __sys_sendto+0x3bd/0x520 net/socket.c:2244 __do_sys_sendto net/socket.c:2251 [inline] __se_sys_sendto net/socket.c:2247 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2247 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f66e998f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006 </TASK>(CVE-2025-68291)
In the Linux kernel, the following vulnerability has been resolved:
tcp: secure_seq: add back ports to TS offset
This reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")
tcp_tw_recycle went away in 2017.
Zhouyan Deng reported off-path TCP source port leakage via SYN cookie side-channel that can be fixed in multiple ways.
One of them is to bring back TCP ports in TS offset randomization.
As a bonus, we perform a single siphash() computation to provide both an ISN and a TS offset.(CVE-2026-23247)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: validate DFA start states are in bounds in unpack_pdb
Start states are read from untrusted data and used as indexes into the DFA state tables. The aa_dfa_next() function call in unpack_pdb() will access dfa->tables[YYTD_ID_BASE][start], and if the start state exceeds the number of states in the DFA, this results in an out-of-bound read.
================================================================== BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360 Read of size 4 at addr ffff88811956fb90 by task su/1097 ...
Reject policies with out-of-bounds start states during unpacking to prevent the issue.(CVE-2026-23269)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix memory leak in ice_set_ringparam()
In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings.
Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails.
Compile tested only. Issue found using a prototype static analysis tool and code review.(CVE-2026-23389)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix race condition during IPSec ESN update
In IPSec full offload mode, the device reports an ESN (Extended Sequence Number) wrap event to the driver. The driver validates this event by querying the IPSec ASO and checking that the esn_event_arm field is 0x0, which indicates an event has occurred. After handling the event, the driver must re-arm the context by setting esn_event_arm back to 0x1.
A race condition exists in this handling path. After validating the event, the driver calls mlx5_accel_esp_modify_xfrm() to update the kernel's xfrm state. This function temporarily releases and re-acquires the xfrm state lock.
So, need to acknowledge the event first by setting esn_event_arm to 0x1. This prevents the driver from reprocessing the same ESN update if the hardware sends events for other reason. Since the next ESN update only occurs after nearly 2^31 packets are received, there's no risk of missing an update, as it will happen long after this handling has finished.
Processing the event twice causes the ESN high-order bits (esn_msb) to be incremented incorrectly. The driver then programs the hardware with this invalid ESN state, which leads to anti-replay failures and a complete halt of IPSec traffic.
Fix this by re-arming the ESN event immediately after it is validated, before calling mlx5_accel_esp_modify_xfrm(). This ensures that any spurious, duplicate events are correctly ignored, closing the race window.(CVE-2026-23440)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent concurrent access to IPSec ASO context
The query or updating IPSec offload object is through Access ASO WQE. The driver uses a single mlx5e_ipsec_aso struct for each PF, which contains a shared DMA-mapped context for all ASO operations.
A race condition exists because the ASO spinlock is released before the hardware has finished processing WQE. If a second operation is initiated immediately after, it overwrites the shared context in the DMA area.
When the first operation's completion is processed later, it reads this corrupted context, leading to unexpected behavior and incorrect results.
This commit fixes the race by introducing a private context within each IPSec offload object. The shared ASO context is now copied to this private context while the ASO spinlock is held. Subsequent processing uses this saved, per-object context, ensuring its integrity is maintained.(CVE-2026-23441)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure
ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do.
Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free.
Document the skb ownership guarantee in the function's kdoc.(CVE-2026-23444)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user
After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del"), l2cap_conn_del() uses conn->lock to protect access to conn->users. However, l2cap_register_user() and l2cap_unregister_user() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2cap_conn_del().
This can lead to use-after-free and list corruption bugs, as reported by syzbot.
Fix this by changing l2cap_register_user() and l2cap_unregister_user() to use conn->lock instead of hci_dev_lock(), ensuring consistent locking for the l2cap_conn structure.(CVE-2026-23461)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access
l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present:
-
L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8).
-
L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5).
A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data.
Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.(CVE-2026-31393)
In the Linux kernel, the following vulnerability has been resolved:
nvdimm/bus: Fix potential use after free in asynchronous initialization
Dingisoul with KASAN reports a use after free if device_add() fails in nd_async_device_register().
Commit b6eae0f61db2 ("libnvdimm: Hold reference on parent while scheduling async init") correctly added a reference on the parent device to be held until asynchronous initialization was complete. However, if device_add() results in an allocation failure the ref count of the device drops to 0 prior to the parent pointer being accessed. Thus resulting in use after free.
The bug bot AI correctly identified the fix. Save a reference to the parent pointer to be used to drop the parent reference regardless of the outcome of device_add().(CVE-2026-31399)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-net: fix OOB access in ULE extension header tables
The ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables in handle_one_ule_extension() are declared with 255 elements (valid indices 0-254), but the index htype is derived from network-controlled data as (ule_sndu_type & 0x00FF), giving a range of 0-255. When htype equals 255, an out-of-bounds read occurs on the function pointer table, and the OOB value may be called as a function pointer.
Add a bounds check on htype against the array size before either table is accessed. Out-of-range values now cause the SNDU to be discarded.(CVE-2026-31405)
In the Linux kernel, the Bluetooth SCO module's sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"perf-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.3.143.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.0.3.143.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"perf-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.3.143.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-145.0.3.143.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: Initialise rcv_mss before calling tcp_send_active_reset() in mptcp_do_fastclose().\n\nsyzbot reported divide-by-zero in __tcp_select_window() by\nMPTCP socket. [0]\n\nWe had a similar issue for the bare TCP and fixed in commit\n499350a5a6e7 (\u0026quot;tcp: initialize rcv_mss to TCP_MIN_MSS instead\nof 0\u0026quot;).\n\nLet\u0026apos;s apply the same fix to mptcp_do_fastclose().\n\n[0]:\nOops: divide error: 0000 [#1] SMP KASAN PTI\nCPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nRIP: 0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336\nCode: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 \u0026lt;f7\u0026gt; 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00\nRSP: 0018:ffffc90003017640 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028\nR10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS: 000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tcp_select_window net/ipv4/tcp_output.c:281 [inline]\n __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568\n tcp_transmit_skb net/ipv4/tcp_output.c:1649 [inline]\n tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836\n mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793\n mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253\n mptcp_sendmsg_fastopen+0x2f8/0x580 net/mptcp/protocol.c:1776\n mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0xe5/0x270 net/socket.c:742\n __sys_sendto+0x3bd/0x520 net/socket.c:2244\n __do_sys_sendto net/socket.c:2251 [inline]\n __se_sys_sendto net/socket.c:2247 [inline]\n __x64_sys_sendto+0xde/0x100 net/socket.c:2247\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f66e998f749\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001\nR13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006\n \u0026lt;/TASK\u0026gt;(CVE-2025-68291)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: secure_seq: add back ports to TS offset\n\nThis reverts 28ee1b746f49 (\u0026quot;secure_seq: downgrade to per-host timestamp offsets\u0026quot;)\n\ntcp_tw_recycle went away in 2017.\n\nZhouyan Deng reported off-path TCP source port leakage via\nSYN cookie side-channel that can be fixed in multiple ways.\n\nOne of them is to bring back TCP ports in TS offset randomization.\n\nAs a bonus, we perform a single siphash() computation\nto provide both an ISN and a TS offset.(CVE-2026-23247)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: validate DFA start states are in bounds in unpack_pdb\n\nStart states are read from untrusted data and used as indexes into the\nDFA state tables. The aa_dfa_next() function call in unpack_pdb() will\naccess dfa-\u0026gt;tables[YYTD_ID_BASE][start], and if the start state exceeds\nthe number of states in the DFA, this results in an out-of-bound read.\n\n==================================================================\n BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360\n Read of size 4 at addr ffff88811956fb90 by task su/1097\n ...\n\nReject policies with out-of-bounds start states during unpacking\nto prevent the issue.(CVE-2026-23269)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix memory leak in ice_set_ringparam()\n\nIn ice_set_ringparam, tx_rings and xdp_rings are allocated before\nrx_rings. If the allocation of rx_rings fails, the code jumps to\nthe done label leaking both tx_rings and xdp_rings. Furthermore, if\nthe setup of an individual Rx ring fails during the loop, the code jumps\nto the free_tx label which releases tx_rings but leaks xdp_rings.\n\nFix this by introducing a free_xdp label and updating the error paths to\nensure both xdp_rings and tx_rings are properly freed if rx_rings\nallocation or setup fails.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.(CVE-2026-23389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix race condition during IPSec ESN update\n\nIn IPSec full offload mode, the device reports an ESN (Extended\nSequence Number) wrap event to the driver. The driver validates this\nevent by querying the IPSec ASO and checking that the esn_event_arm\nfield is 0x0, which indicates an event has occurred. After handling\nthe event, the driver must re-arm the context by setting esn_event_arm\nback to 0x1.\n\nA race condition exists in this handling path. After validating the\nevent, the driver calls mlx5_accel_esp_modify_xfrm() to update the\nkernel\u0026apos;s xfrm state. This function temporarily releases and\nre-acquires the xfrm state lock.\n\nSo, need to acknowledge the event first by setting esn_event_arm to\n0x1. This prevents the driver from reprocessing the same ESN update if\nthe hardware sends events for other reason. Since the next ESN update\nonly occurs after nearly 2^31 packets are received, there\u0026apos;s no risk of\nmissing an update, as it will happen long after this handling has\nfinished.\n\nProcessing the event twice causes the ESN high-order bits (esn_msb) to\nbe incremented incorrectly. The driver then programs the hardware with\nthis invalid ESN state, which leads to anti-replay failures and a\ncomplete halt of IPSec traffic.\n\nFix this by re-arming the ESN event immediately after it is validated,\nbefore calling mlx5_accel_esp_modify_xfrm(). This ensures that any\nspurious, duplicate events are correctly ignored, closing the race\nwindow.(CVE-2026-23440)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Prevent concurrent access to IPSec ASO context\n\nThe query or updating IPSec offload object is through Access ASO WQE.\nThe driver uses a single mlx5e_ipsec_aso struct for each PF, which\ncontains a shared DMA-mapped context for all ASO operations.\n\nA race condition exists because the ASO spinlock is released before\nthe hardware has finished processing WQE. If a second operation is\ninitiated immediately after, it overwrites the shared context in the\nDMA area.\n\nWhen the first operation\u0026apos;s completion is processed later, it reads\nthis corrupted context, leading to unexpected behavior and incorrect\nresults.\n\nThis commit fixes the race by introducing a private context within\neach IPSec offload object. The shared ASO context is now copied to\nthis private context while the ASO spinlock is held. Subsequent\nprocessing uses this saved, per-object context, ensuring its integrity\nis maintained.(CVE-2026-23441)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure\n\nieee80211_tx_prepare_skb() has three error paths, but only two of them\nfree the skb. The first error path (ieee80211_tx_prepare() returning\nTX_DROP) does not free it, while invoke_tx_handlers() failure and the\nfragmentation check both do.\n\nAdd kfree_skb() to the first error path so all three are consistent,\nand remove the now-redundant frees in callers (ath9k, mt76,\nmac80211_hwsim) to avoid double-free.\n\nDocument the skb ownership guarantee in the function\u0026apos;s kdoc.(CVE-2026-23444)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user\n\nAfter commit ab4eedb790ca (\u0026quot;Bluetooth: L2CAP: Fix corrupted list in\nhci_chan_del\u0026quot;), l2cap_conn_del() uses conn-\u0026gt;lock to protect access to\nconn-\u0026gt;users. However, l2cap_register_user() and l2cap_unregister_user()\ndon\u0026apos;t use conn-\u0026gt;lock, creating a race condition where these functions can\naccess conn-\u0026gt;users and conn-\u0026gt;hchan concurrently with l2cap_conn_del().\n\nThis can lead to use-after-free and list corruption bugs, as reported\nby syzbot.\n\nFix this by changing l2cap_register_user() and l2cap_unregister_user()\nto use conn-\u0026gt;lock instead of hci_dev_lock(), ensuring consistent locking\nfor the l2cap_conn structure.(CVE-2026-23461)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access\n\nl2cap_information_rsp() checks that cmd_len covers the fixed\nl2cap_info_rsp header (type + result, 4 bytes) but then reads\nrsp-\u0026gt;data without verifying that the payload is present:\n\n - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp-\u0026gt;data), which reads\n 4 bytes past the header (needs cmd_len \u0026gt;= 8).\n\n - L2CAP_IT_FIXED_CHAN reads rsp-\u0026gt;data[0], 1 byte past the header\n (needs cmd_len \u0026gt;= 5).\n\nA truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an\nout-of-bounds read of adjacent skb data.\n\nGuard each data access with the required payload length check. If the\npayload is too short, skip the read and let the state machine complete\nwith safe defaults (feat_mask and remote_fixed_chan remain zero from\nkzalloc), so the info timer cleanup and l2cap_conn_start() still run\nand the connection is not stalled.(CVE-2026-31393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvdimm/bus: Fix potential use after free in asynchronous initialization\n\nDingisoul with KASAN reports a use after free if device_add() fails in\nnd_async_device_register().\n\nCommit b6eae0f61db2 (\u0026quot;libnvdimm: Hold reference on parent while\nscheduling async init\u0026quot;) correctly added a reference on the parent device\nto be held until asynchronous initialization was complete. However, if\ndevice_add() results in an allocation failure the ref count of the\ndevice drops to 0 prior to the parent pointer being accessed. Thus\nresulting in use after free.\n\nThe bug bot AI correctly identified the fix. Save a reference to the\nparent pointer to be used to drop the parent reference regardless of the\noutcome of device_add().(CVE-2026-31399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-net: fix OOB access in ULE extension header tables\n\nThe ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables\nin handle_one_ule_extension() are declared with 255 elements (valid\nindices 0-254), but the index htype is derived from network-controlled\ndata as (ule_sndu_type \u0026amp; 0x00FF), giving a range of 0-255. When\nhtype equals 255, an out-of-bounds read occurs on the function pointer\ntable, and the OOB value may be called as a function pointer.\n\nAdd a bounds check on htype against the array size before either table\nis accessed. Out-of-range values now cause the SNDU to be discarded.(CVE-2026-31405)\n\nIn the Linux kernel, the Bluetooth SCO module\u0026apos;s sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn-\u0026gt;sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk-\u0026gt;sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)",
"id": "OESA-2026-1947",
"modified": "2026-08-06T11:10:57Z",
"published": "2026-04-17T11:10:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68291"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23247"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23389"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23440"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23441"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23444"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23461"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31399"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31405"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31408"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-68291",
"CVE-2026-23247",
"CVE-2026-23269",
"CVE-2026-23389",
"CVE-2026-23440",
"CVE-2026-23441",
"CVE-2026-23444",
"CVE-2026-23461",
"CVE-2026-31393",
"CVE-2026-31399",
"CVE-2026-31405",
"CVE-2026-31408"
]
}
OESA-2026-1948 (CVE-2025-68291)
Vulnerability from osv_openeuler – Published: 2026-04-17 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in mptcp_do_fastclose().
syzbot reported divide-by-zero in __tcp_select_window() by MPTCP socket. [0]
We had a similar issue for the bare TCP and fixed in commit 499350a5a6e7 ("tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0").
Let's apply the same fix to mptcp_do_fastclose().
[0]: Oops: divide error: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 RIP: 0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336 Code: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 <f7> 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00 RSP: 0018:ffffc90003017640 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028 R10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0 Call Trace: <TASK> tcp_select_window net/ipv4/tcp_output.c:281 [inline] __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568 tcp_transmit_skb net/ipv4/tcp_output.c:1649 [inline] tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836 mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793 mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253 mptcp_sendmsg_fastopen+0x2f8/0x580 net/mptcp/protocol.c:1776 mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe5/0x270 net/socket.c:742 __sys_sendto+0x3bd/0x520 net/socket.c:2244 __do_sys_sendto net/socket.c:2251 [inline] __se_sys_sendto net/socket.c:2247 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2247 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f66e998f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006 </TASK>(CVE-2025-68291)
In the Linux kernel, the following vulnerability has been resolved:
tcp: secure_seq: add back ports to TS offset
This reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")
tcp_tw_recycle went away in 2017.
Zhouyan Deng reported off-path TCP source port leakage via SYN cookie side-channel that can be fixed in multiple ways.
One of them is to bring back TCP ports in TS offset randomization.
As a bonus, we perform a single siphash() computation to provide both an ISN and a TS offset.(CVE-2026-23247)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: validate DFA start states are in bounds in unpack_pdb
Start states are read from untrusted data and used as indexes into the DFA state tables. The aa_dfa_next() function call in unpack_pdb() will access dfa->tables[YYTD_ID_BASE][start], and if the start state exceeds the number of states in the DFA, this results in an out-of-bound read.
================================================================== BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360 Read of size 4 at addr ffff88811956fb90 by task su/1097 ...
Reject policies with out-of-bounds start states during unpacking to prevent the issue.(CVE-2026-23269)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix memory leak in ice_set_ringparam()
In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings.
Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails.
Compile tested only. Issue found using a prototype static analysis tool and code review.(CVE-2026-23389)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix race condition during IPSec ESN update
In IPSec full offload mode, the device reports an ESN (Extended Sequence Number) wrap event to the driver. The driver validates this event by querying the IPSec ASO and checking that the esn_event_arm field is 0x0, which indicates an event has occurred. After handling the event, the driver must re-arm the context by setting esn_event_arm back to 0x1.
A race condition exists in this handling path. After validating the event, the driver calls mlx5_accel_esp_modify_xfrm() to update the kernel's xfrm state. This function temporarily releases and re-acquires the xfrm state lock.
So, need to acknowledge the event first by setting esn_event_arm to 0x1. This prevents the driver from reprocessing the same ESN update if the hardware sends events for other reason. Since the next ESN update only occurs after nearly 2^31 packets are received, there's no risk of missing an update, as it will happen long after this handling has finished.
Processing the event twice causes the ESN high-order bits (esn_msb) to be incremented incorrectly. The driver then programs the hardware with this invalid ESN state, which leads to anti-replay failures and a complete halt of IPSec traffic.
Fix this by re-arming the ESN event immediately after it is validated, before calling mlx5_accel_esp_modify_xfrm(). This ensures that any spurious, duplicate events are correctly ignored, closing the race window.(CVE-2026-23440)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent concurrent access to IPSec ASO context
The query or updating IPSec offload object is through Access ASO WQE. The driver uses a single mlx5e_ipsec_aso struct for each PF, which contains a shared DMA-mapped context for all ASO operations.
A race condition exists because the ASO spinlock is released before the hardware has finished processing WQE. If a second operation is initiated immediately after, it overwrites the shared context in the DMA area.
When the first operation's completion is processed later, it reads this corrupted context, leading to unexpected behavior and incorrect results.
This commit fixes the race by introducing a private context within each IPSec offload object. The shared ASO context is now copied to this private context while the ASO spinlock is held. Subsequent processing uses this saved, per-object context, ensuring its integrity is maintained.(CVE-2026-23441)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure
ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do.
Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free.
Document the skb ownership guarantee in the function's kdoc.(CVE-2026-23444)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user
After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del"), l2cap_conn_del() uses conn->lock to protect access to conn->users. However, l2cap_register_user() and l2cap_unregister_user() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2cap_conn_del().
This can lead to use-after-free and list corruption bugs, as reported by syzbot.
Fix this by changing l2cap_register_user() and l2cap_unregister_user() to use conn->lock instead of hci_dev_lock(), ensuring consistent locking for the l2cap_conn structure.(CVE-2026-23461)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access
l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present:
-
L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8).
-
L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5).
A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data.
Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.(CVE-2026-31393)
In the Linux kernel, the following vulnerability has been resolved:
nvdimm/bus: Fix potential use after free in asynchronous initialization
Dingisoul with KASAN reports a use after free if device_add() fails in nd_async_device_register().
Commit b6eae0f61db2 ("libnvdimm: Hold reference on parent while scheduling async init") correctly added a reference on the parent device to be held until asynchronous initialization was complete. However, if device_add() results in an allocation failure the ref count of the device drops to 0 prior to the parent pointer being accessed. Thus resulting in use after free.
The bug bot AI correctly identified the fix. Save a reference to the parent pointer to be used to drop the parent reference regardless of the outcome of device_add().(CVE-2026-31399)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-net: fix OOB access in ULE extension header tables
The ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables in handle_one_ule_extension() are declared with 255 elements (valid indices 0-254), but the index htype is derived from network-controlled data as (ule_sndu_type & 0x00FF), giving a range of 0-255. When htype equals 255, an out-of-bounds read occurs on the function pointer table, and the OOB value may be called as a function pointer.
Add a bounds check on htype against the array size before either table is accessed. Out-of-range values now cause the SNDU to be discarded.(CVE-2026-31405)
In the Linux kernel, the Bluetooth SCO module's sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"perf-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.3.144.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.0.3.144.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"perf-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.3.144.oe2403sp2.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP2",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-145.0.3.144.oe2403sp2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: Initialise rcv_mss before calling tcp_send_active_reset() in mptcp_do_fastclose().\n\nsyzbot reported divide-by-zero in __tcp_select_window() by\nMPTCP socket. [0]\n\nWe had a similar issue for the bare TCP and fixed in commit\n499350a5a6e7 (\u0026quot;tcp: initialize rcv_mss to TCP_MIN_MSS instead\nof 0\u0026quot;).\n\nLet\u0026apos;s apply the same fix to mptcp_do_fastclose().\n\n[0]:\nOops: divide error: 0000 [#1] SMP KASAN PTI\nCPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nRIP: 0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336\nCode: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 \u0026lt;f7\u0026gt; 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00\nRSP: 0018:ffffc90003017640 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028\nR10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS: 000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tcp_select_window net/ipv4/tcp_output.c:281 [inline]\n __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568\n tcp_transmit_skb net/ipv4/tcp_output.c:1649 [inline]\n tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836\n mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793\n mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253\n mptcp_sendmsg_fastopen+0x2f8/0x580 net/mptcp/protocol.c:1776\n mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0xe5/0x270 net/socket.c:742\n __sys_sendto+0x3bd/0x520 net/socket.c:2244\n __do_sys_sendto net/socket.c:2251 [inline]\n __se_sys_sendto net/socket.c:2247 [inline]\n __x64_sys_sendto+0xde/0x100 net/socket.c:2247\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f66e998f749\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001\nR13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006\n \u0026lt;/TASK\u0026gt;(CVE-2025-68291)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: secure_seq: add back ports to TS offset\n\nThis reverts 28ee1b746f49 (\u0026quot;secure_seq: downgrade to per-host timestamp offsets\u0026quot;)\n\ntcp_tw_recycle went away in 2017.\n\nZhouyan Deng reported off-path TCP source port leakage via\nSYN cookie side-channel that can be fixed in multiple ways.\n\nOne of them is to bring back TCP ports in TS offset randomization.\n\nAs a bonus, we perform a single siphash() computation\nto provide both an ISN and a TS offset.(CVE-2026-23247)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: validate DFA start states are in bounds in unpack_pdb\n\nStart states are read from untrusted data and used as indexes into the\nDFA state tables. The aa_dfa_next() function call in unpack_pdb() will\naccess dfa-\u0026gt;tables[YYTD_ID_BASE][start], and if the start state exceeds\nthe number of states in the DFA, this results in an out-of-bound read.\n\n==================================================================\n BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360\n Read of size 4 at addr ffff88811956fb90 by task su/1097\n ...\n\nReject policies with out-of-bounds start states during unpacking\nto prevent the issue.(CVE-2026-23269)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix memory leak in ice_set_ringparam()\n\nIn ice_set_ringparam, tx_rings and xdp_rings are allocated before\nrx_rings. If the allocation of rx_rings fails, the code jumps to\nthe done label leaking both tx_rings and xdp_rings. Furthermore, if\nthe setup of an individual Rx ring fails during the loop, the code jumps\nto the free_tx label which releases tx_rings but leaks xdp_rings.\n\nFix this by introducing a free_xdp label and updating the error paths to\nensure both xdp_rings and tx_rings are properly freed if rx_rings\nallocation or setup fails.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.(CVE-2026-23389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix race condition during IPSec ESN update\n\nIn IPSec full offload mode, the device reports an ESN (Extended\nSequence Number) wrap event to the driver. The driver validates this\nevent by querying the IPSec ASO and checking that the esn_event_arm\nfield is 0x0, which indicates an event has occurred. After handling\nthe event, the driver must re-arm the context by setting esn_event_arm\nback to 0x1.\n\nA race condition exists in this handling path. After validating the\nevent, the driver calls mlx5_accel_esp_modify_xfrm() to update the\nkernel\u0026apos;s xfrm state. This function temporarily releases and\nre-acquires the xfrm state lock.\n\nSo, need to acknowledge the event first by setting esn_event_arm to\n0x1. This prevents the driver from reprocessing the same ESN update if\nthe hardware sends events for other reason. Since the next ESN update\nonly occurs after nearly 2^31 packets are received, there\u0026apos;s no risk of\nmissing an update, as it will happen long after this handling has\nfinished.\n\nProcessing the event twice causes the ESN high-order bits (esn_msb) to\nbe incremented incorrectly. The driver then programs the hardware with\nthis invalid ESN state, which leads to anti-replay failures and a\ncomplete halt of IPSec traffic.\n\nFix this by re-arming the ESN event immediately after it is validated,\nbefore calling mlx5_accel_esp_modify_xfrm(). This ensures that any\nspurious, duplicate events are correctly ignored, closing the race\nwindow.(CVE-2026-23440)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Prevent concurrent access to IPSec ASO context\n\nThe query or updating IPSec offload object is through Access ASO WQE.\nThe driver uses a single mlx5e_ipsec_aso struct for each PF, which\ncontains a shared DMA-mapped context for all ASO operations.\n\nA race condition exists because the ASO spinlock is released before\nthe hardware has finished processing WQE. If a second operation is\ninitiated immediately after, it overwrites the shared context in the\nDMA area.\n\nWhen the first operation\u0026apos;s completion is processed later, it reads\nthis corrupted context, leading to unexpected behavior and incorrect\nresults.\n\nThis commit fixes the race by introducing a private context within\neach IPSec offload object. The shared ASO context is now copied to\nthis private context while the ASO spinlock is held. Subsequent\nprocessing uses this saved, per-object context, ensuring its integrity\nis maintained.(CVE-2026-23441)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure\n\nieee80211_tx_prepare_skb() has three error paths, but only two of them\nfree the skb. The first error path (ieee80211_tx_prepare() returning\nTX_DROP) does not free it, while invoke_tx_handlers() failure and the\nfragmentation check both do.\n\nAdd kfree_skb() to the first error path so all three are consistent,\nand remove the now-redundant frees in callers (ath9k, mt76,\nmac80211_hwsim) to avoid double-free.\n\nDocument the skb ownership guarantee in the function\u0026apos;s kdoc.(CVE-2026-23444)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user\n\nAfter commit ab4eedb790ca (\u0026quot;Bluetooth: L2CAP: Fix corrupted list in\nhci_chan_del\u0026quot;), l2cap_conn_del() uses conn-\u0026gt;lock to protect access to\nconn-\u0026gt;users. However, l2cap_register_user() and l2cap_unregister_user()\ndon\u0026apos;t use conn-\u0026gt;lock, creating a race condition where these functions can\naccess conn-\u0026gt;users and conn-\u0026gt;hchan concurrently with l2cap_conn_del().\n\nThis can lead to use-after-free and list corruption bugs, as reported\nby syzbot.\n\nFix this by changing l2cap_register_user() and l2cap_unregister_user()\nto use conn-\u0026gt;lock instead of hci_dev_lock(), ensuring consistent locking\nfor the l2cap_conn structure.(CVE-2026-23461)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access\n\nl2cap_information_rsp() checks that cmd_len covers the fixed\nl2cap_info_rsp header (type + result, 4 bytes) but then reads\nrsp-\u0026gt;data without verifying that the payload is present:\n\n - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp-\u0026gt;data), which reads\n 4 bytes past the header (needs cmd_len \u0026gt;= 8).\n\n - L2CAP_IT_FIXED_CHAN reads rsp-\u0026gt;data[0], 1 byte past the header\n (needs cmd_len \u0026gt;= 5).\n\nA truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an\nout-of-bounds read of adjacent skb data.\n\nGuard each data access with the required payload length check. If the\npayload is too short, skip the read and let the state machine complete\nwith safe defaults (feat_mask and remote_fixed_chan remain zero from\nkzalloc), so the info timer cleanup and l2cap_conn_start() still run\nand the connection is not stalled.(CVE-2026-31393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvdimm/bus: Fix potential use after free in asynchronous initialization\n\nDingisoul with KASAN reports a use after free if device_add() fails in\nnd_async_device_register().\n\nCommit b6eae0f61db2 (\u0026quot;libnvdimm: Hold reference on parent while\nscheduling async init\u0026quot;) correctly added a reference on the parent device\nto be held until asynchronous initialization was complete. However, if\ndevice_add() results in an allocation failure the ref count of the\ndevice drops to 0 prior to the parent pointer being accessed. Thus\nresulting in use after free.\n\nThe bug bot AI correctly identified the fix. Save a reference to the\nparent pointer to be used to drop the parent reference regardless of the\noutcome of device_add().(CVE-2026-31399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-net: fix OOB access in ULE extension header tables\n\nThe ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables\nin handle_one_ule_extension() are declared with 255 elements (valid\nindices 0-254), but the index htype is derived from network-controlled\ndata as (ule_sndu_type \u0026amp; 0x00FF), giving a range of 0-255. When\nhtype equals 255, an out-of-bounds read occurs on the function pointer\ntable, and the OOB value may be called as a function pointer.\n\nAdd a bounds check on htype against the array size before either table\nis accessed. Out-of-range values now cause the SNDU to be discarded.(CVE-2026-31405)\n\nIn the Linux kernel, the Bluetooth SCO module\u0026apos;s sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn-\u0026gt;sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk-\u0026gt;sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)",
"id": "OESA-2026-1948",
"modified": "2026-08-06T11:10:57Z",
"published": "2026-04-17T11:10:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1948"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68291"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23247"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23389"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23440"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23441"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23444"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23461"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31399"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31405"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31408"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-68291",
"CVE-2026-23247",
"CVE-2026-23269",
"CVE-2026-23389",
"CVE-2026-23440",
"CVE-2026-23441",
"CVE-2026-23444",
"CVE-2026-23461",
"CVE-2026-31393",
"CVE-2026-31399",
"CVE-2026-31405",
"CVE-2026-31408"
]
}
OESA-2026-2416 (CVE-2025-38488)
Vulnerability from osv_openeuler – Published: 2026-05-22 11:11 – Updated: 2026-08-06 11:11 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in crypt_message when using async crypto
The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:
crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req);
// Async encryption returns -EINPROGRESS immediately
rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);
// Free creq while async operation is still in progress
kvfree_sensitive(creq, ...);
Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.
This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.
The issue occurs because crypto_alloc_aead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected.
Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callback() for async completion notification - crypto_wait_req() to wait for operation completion
This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.(CVE-2025-38488)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix buffer free/clear order in deferred receive path
Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF.
Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same.(CVE-2025-39841)
In the Linux kernel, the following vulnerability has been resolved:
nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()
nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur:
[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] <TASK> [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] </TASK>(CVE-2025-40261)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix crash in nfsd4_read_release()
When tracing is enabled, the trace_nfsd_read_done trace point crashes during the pynfs read.testNoFh test.(CVE-2025-40324)
In the Linux kernel, the following vulnerability has been resolved:
nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing
Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack.
Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that.(CVE-2025-68185)
In the Linux kernel, the following vulnerability has been resolved:
timers: Fix NULL function pointer race in timer_shutdown_sync()
There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers().
The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this:
CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base()
The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers().
Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.(CVE-2025-68214)
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: Fix memory leak in USB bulk transport
A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355.
When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB.
Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase.
Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.(CVE-2025-68288)
In the Linux kernel, the following vulnerability has been resolved:
ext4: xattr: fix null pointer deref in ext4_raw_inode()
If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED), iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all() lacks error checking, this will lead to a null pointer dereference in ext4_raw_inode(), called right after ext4_get_inode_loc().
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68820)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: using the num_tqps in the vf driver to apply for resources
Currently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqp is allocated using kinfo->num_tqps. However, kinfo->num_tqps is set to min(new_tqps, hdev->num_tqps); Therefore, kinfo->num_tqps may be smaller than hdev->num_tqps, which causes some hdev->htqp[i] to remain uninitialized in hclgevf_knic_setup().
Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps, ensuring that the lengths of hdev->htqp and kinfo->tqp are consistent and that all elements are properly initialized.(CVE-2025-71064)
In the Linux kernel, the following vulnerability has been resolved:
macvlan: observe an RCU grace period in macvlan_common_newlink() error path
valis reported that a race condition still happens after my prior patch.
macvlan_common_newlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev).
We must respect an RCU period, either in macvlan or the core networking stack.
After adding a temporary mdelay(1000) in macvlan_forward_source_one() to open the race window, valis repro was:
ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source
(ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument
BUG: KASAN: slab-use-after-free in macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175
CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasan_report (mm/kasan/report.c:597) ? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) ? tasklet_init (kernel/softirq.c:983) macvlan_handle_frame (drivers/net/macvlan.c:501)
Allocated by task 169: kasan_save_stack (mm/kasan/common.c:58) kasan_save_track (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) __kasan_kmalloc (mm/kasan/common.c:419) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5657 mm/slub.c:7140) alloc_netdev_mqs (net/core/dev.c:12012) rtnl_create_link (net/core/rtnetlink.c:3648) rtnl_newlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)
Freed by task 169: kasan_save_stack (mm/kasan/common.c:58) kasan_save_track (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) kasan_save_free_info (mm/kasan/generic.c:587) __kasan_slab_free (mm/kasan/common.c:287) kfree (mm/slub.c:6674 mm/slub.c:6882) rtnl_newlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)(CVE-2026-23273)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access
l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present:
-
L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8).
-
L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5).
A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data.
Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.(CVE-2026-31393)
In the Linux kernel, the following vulnerability has been resolved:
ext4: reject mount if bigalloc with s_first_data_block != 0
bigalloc with s_first_data_block != 0 is not supported, reject mounting it.(CVE-2026-31447)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix memory leaks and NULL deref in smb2_lock()
smb2_lock() has three error handling issues after list_del() detaches smb_lock from lock_list at no_check_cl:
1) If vfs_lock_file() returns an unexpected error in the non-UNLOCK path, goto out leaks smb_lock and its flock because the out: handler only iterates lock_list and rollback_list, neither of which contains the detached smb_lock.
2) If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out leaks smb_lock and flock for the same reason. The error code returned to the dispatcher is also stale.
3) In the rollback path, smb_flock_init() can return NULL on allocation failure. The result is dereferenced unconditionally, causing a kernel NULL pointer dereference. Add a NULL check to prevent the crash and clean up the bookkeeping; the VFS lock itself cannot be rolled back without the allocation and will be released at file or connection teardown.
Fix cases 1 and 2 by hoisting the locks_free_lock()/kfree() to before the if(!rc) check in the UNLOCK branch so all exit paths share one free site, and by freeing smb_lock and flock before goto out in the non-UNLOCK branch. Propagate the correct error code in both cases. Fix case 3 by wrapping the VFS unlock in an if(rlock) guard and adding a NULL check for locks_free_lock(rlock) in the shared cleanup.
Found via call-graph analysis using sqry.(CVE-2026-31477)
In the Linux kernel, the following vulnerability has been resolved:
driver core: platform: use generic driver_override infrastructure
When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.
Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.
Note that calling match() from __driver_attach() without the device lock held is intentional. 1
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: require 3 sub-authorities before reading sub_auth[2]
parse_dacl() compares each ACE SID against sid_unix_NFS_mode and on match reads sid.sub_auth[2] as the file mode. If sid_unix_NFS_mode is the prefix S-1-5-88-3 with num_subauth = 2 then compare_sids() compares only min(num_subauth, 2) sub-authorities so a client SID with num_subauth = 2 and sub_auth = {88, 3} will match.
If num_subauth = 2 and the ACE is placed at the very end of the security descriptor, sub_auth[2] will be 4 bytes past end_of_acl. The out-of-band bytes will then be masked to the low 9 bits and applied as the file's POSIX mode, probably not something that is good to have happen.
Fix this up by forcing the SID to actually carry a third sub-authority before reading it at all.(CVE-2026-31611)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate EaNameLength in smb2_get_ea()
smb2_get_ea() reads ea_req->EaNameLength from the client request and passes it directly to strncmp() as the comparison length without verifying that the length of the name really is the size of the input buffer received.
Fix this up by properly checking the size of the name based on the value received and the overall size of the request, to prevent a later strncmp() call to use the length as a "trusted" size of the buffer. Without this check, uninitialized heap values might be slowly leaked to the client.(CVE-2026-31612)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: use check_add_overflow() to prevent u16 DACL size overflow
set_posix_acl_entries_dacl() and set_ntacl_dacl() accumulate ACE sizes in u16 variables. When a file has many POSIX ACL entries, the accumulated size can wrap past 65535, causing the pointer arithmetic (char )pndace + size to land within already-written ACEs. Subsequent writes then overwrite earlier entries, and pndacl->size gets a truncated value.
Use check_add_overflow() at each accumulation point to detect the wrap before it corrupts the buffer, consistent with existing check_mul_overflow() usage elsewhere in smbacl.c.(CVE-2026-31704)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path
smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. The QUERY_INFO branch clamps qi.input_buffer_length to the server-reported OutputBufferLength and then copies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rsp_iov[1].iov_len.
A malicious server can return OutputBufferLength larger than the actual QUERY_INFO response, causing copy_to_user() to walk past the response buffer and expose adjacent kernel heap to userspace.
Guard the QUERY_INFO copy with a bounds check on the actual Buffer payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.(CVE-2026-31708)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: gadget: fix state inconsistency on gadget init failure
When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency.
When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role
The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles.
This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller:
[ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch
Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state.(CVE-2026-31754)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: gadget: fix NULL pointer dereference in ep_queue
When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when __cdns3_gadget_ep_queue() is called, causing a kernel crash.
Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints.
This prevents potential crashes when ep_queue is called on endpoints that are not ready.(CVE-2026-31755)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: move wake reason storage into validated event handlers
hci_store_wake_reason() is called from hci_event_packet() immediately after stripping the HCI event header but before hci_event_func() enforces the per-event minimum payload length from hci_ev_table. This means a short HCI event frame can reach bacpy() before any bounds check runs.
Rather than duplicating skb parsing and per-event length checks inside hci_store_wake_reason(), move wake-address storage into the individual event handlers after their existing event-length validation has succeeded. Convert hci_store_wake_reason() into a small helper that only stores an already-validated bdaddr while the caller holds hci_dev_lock(). Use the same helper after hci_event_func() with a NULL address to preserve the existing unexpected-wake fallback semantics when no validated event handler records a wake address.
Annotate the helper with __must_hold(&hdev->lock) and add lockdep_assert_held(&hdev->lock) so future call paths keep the lock contract explicit.
Call the helper from hci_conn_request_evt(), hci_conn_complete_evt(), hci_sync_conn_complete_evt(), le_conn_complete_evt(), hci_le_adv_report_evt(), hci_le_ext_adv_report_evt(), hci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), and hci_le_past_received_evt().(CVE-2026-31771)
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: Check to ensure report responses match the request
It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes.
Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.(CVE-2026-43047)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: Mitigate potential OOB by removing bogus memset()
The memset() in hid_report_raw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution.
The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report.
Suggested-by Benjamin Tissoires <(CVE-2026-43048)
In the Linux kernel, the following vulnerability has been resolved:
EFI/CPER: don't dump the entire memory region
The current logic at cper_print_fw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory.
The end result can be:
- the logic taking a lot of time dumping large regions of memory;
- data disclosure due to the memory dumps;
- an OOPS, if it tries to dump an unmapped memory region.
Fix it by checking if the section length is too small before doing a hex dump.
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE
The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE - which is a valid index - so add a check for this.(CVE-2026-43212)
In the Linux kernel, the following vulnerability has been resolved:
arm64: Add support for TSV110 Spectre-BHB mitigation
The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation.(CVE-2026-43261)
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Limit the length of unkillable synchronous timeouts
The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device.
To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector.
In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.(CVE-2026-43428)
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Prevent interrupt storm on host controller error (HCE)
The xHCI controller reports a Host Controller Error (HCE) in UAS Storage Device plug/unplug scenarios on Android devices. HCE is checked in xhci_irq() function and causes an interrupt storm (since the interrupt isn’t cleared), leading to severe system-level faults.
When the xHC controller reports HCE in the interrupt handler, the driver only logs a warning and assumes xHC activity will stop as stated in xHCI specification. An interrupt storm does however continue on some hosts even after HCE, and only ceases after manually disabling xHC interrupt and stopping the controller by calling xhci_halt().
Add xhci_halt() to xhci_irq() function where STS_HCE status is checked, mirroring the existing error handling pattern used for STS_FATAL errors.
This only fixes the interrupt storm. Proper HCE recovery requires resetting and re-initializing the xHC.(CVE-2026-43488)
In the Linux kernel, the following vulnerability has been resolved:
ptrace: slightly saner 'get_dumpable()' logic
The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm.
And almost all users do in fact use it only for the case where the task has a mm pointer.
But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads).
It's not what this flag was designed for, but it is what it is.
The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all.
Make it all make a bit more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.(CVE-2026-46333)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"perf-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-315.0.0.218.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-315.0.0.218.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"perf-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-315.0.0.218.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-315.0.0.218.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in crypt_message when using async crypto\n\nThe CVE-2024-50047 fix removed asynchronous crypto handling from\ncrypt_message(), assuming all crypto operations are synchronous.\nHowever, when hardware crypto accelerators are used, this can cause\nuse-after-free crashes:\n\n crypt_message()\n // Allocate the creq buffer containing the req\n creq = smb2_get_aead_req(..., \u0026amp;req);\n\n // Async encryption returns -EINPROGRESS immediately\n rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);\n\n // Free creq while async operation is still in progress\n kvfree_sensitive(creq, ...);\n\nHardware crypto modules often implement async AEAD operations for\nperformance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,\nthe operation completes asynchronously. Without crypto_wait_req(),\nthe function immediately frees the request buffer, leading to crashes\nwhen the driver later accesses the freed memory.\n\nThis results in a use-after-free condition when the hardware crypto\ndriver later accesses the freed request structure, leading to kernel\ncrashes with NULL pointer dereferences.\n\nThe issue occurs because crypto_alloc_aead() with mask=0 doesn\u0026apos;t\nguarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in\nthe mask, async implementations can be selected.\n\nFix by restoring the async crypto handling:\n- DECLARE_CRYPTO_WAIT(wait) for completion tracking\n- aead_request_set_callback() for async completion notification\n- crypto_wait_req() to wait for operation completion\n\nThis ensures the request buffer isn\u0026apos;t freed until the crypto operation\ncompletes, whether synchronous or asynchronous, while preserving the\nCVE-2024-50047 fix.(CVE-2025-38488)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix buffer free/clear order in deferred receive path\n\nFix a use-after-free window by correcting the buffer release sequence in\nthe deferred receive path. The code freed the RQ buffer first and only\nthen cleared the context pointer under the lock. Concurrent paths (e.g.,\nABTS and the repost path) also inspect and release the same pointer under\nthe lock, so the old order could lead to double-free/UAF.\n\nNote that the repost path already uses the correct pattern: detach the\npointer under the lock, then free it after dropping the lock. The\ndeferred path should do the same.(CVE-2025-39841)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: nvme-fc: Ensure -\u0026gt;ioerr_work is cancelled in nvme_fc_delete_ctrl()\n\nnvme_fc_delete_assocation() waits for pending I/O to complete before\nreturning, and an error can cause -\u0026gt;ioerr_work to be queued after\ncancel_work_sync() had been called. Move the call to cancel_work_sync() to\nbe after nvme_fc_delete_association() to ensure -\u0026gt;ioerr_work is not running\nwhen the nvme_fc_ctrl object is freed. Otherwise the following can occur:\n\n[ 1135.911754] list_del corruption, ff2d24c8093f31f8-\u0026gt;next is NULL\n[ 1135.917705] ------------[ cut here ]------------\n[ 1135.922336] kernel BUG at lib/list_debug.c:52!\n[ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI\n[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)\n[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025\n[ 1135.950969] Workqueue: 0x0 (nvme-wq)\n[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff \u0026lt;0f\u0026gt; 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b\n[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046\n[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000\n[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0\n[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08\n[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100\n[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0\n[ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000\n[ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0\n[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n[ 1136.055910] PKRU: 55555554\n[ 1136.058623] Call Trace:\n[ 1136.061074] \u0026lt;TASK\u0026gt;\n[ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0\n[ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0\n[ 1136.071898] ? move_linked_works+0x4a/0xa0\n[ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.081744] ? __die_body.cold+0x8/0x12\n[ 1136.085584] ? die+0x2e/0x50\n[ 1136.088469] ? do_trap+0xca/0x110\n[ 1136.091789] ? do_error_trap+0x65/0x80\n[ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.101289] ? exc_invalid_op+0x50/0x70\n[ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20\n[ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.120806] move_linked_works+0x4a/0xa0\n[ 1136.124733] worker_thread+0x216/0x3a0\n[ 1136.128485] ? __pfx_worker_thread+0x10/0x10\n[ 1136.132758] kthread+0xfa/0x240\n[ 1136.135904] ? __pfx_kthread+0x10/0x10\n[ 1136.139657] ret_from_fork+0x31/0x50\n[ 1136.143236] ? __pfx_kthread+0x10/0x10\n[ 1136.146988] ret_from_fork_asm+0x1a/0x30\n[ 1136.150915] \u0026lt;/TASK\u0026gt;(CVE-2025-40261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Fix crash in nfsd4_read_release()\n\nWhen tracing is enabled, the trace_nfsd_read_done trace point\ncrashes during the pynfs read.testNoFh test.(CVE-2025-40324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfs4_setup_readdir(): insufficient locking for -\u0026gt;d_parent-\u0026gt;d_inode dereferencing\n\nTheoretically it\u0026apos;s an oopsable race, but I don\u0026apos;t believe one can manage\nto hit it on real hardware; might become doable on a KVM, but it still\nwon\u0026apos;t be easy to attack.\n\nAnyway, it\u0026apos;s easy to deal with - since xdr_encode_hyper() is just a call of\nput_unaligned_be64(), we can put that under -\u0026gt;d_lock and be done with that.(CVE-2025-68185)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntimers: Fix NULL function pointer race in timer_shutdown_sync()\n\nThere is a race condition between timer_shutdown_sync() and timer\nexpiration that can lead to hitting a WARN_ON in expire_timers().\n\nThe issue occurs when timer_shutdown_sync() clears the timer function\nto NULL while the timer is still running on another CPU. The race\nscenario looks like this:\n\nCPU0\t\t\t\t\tCPU1\n\t\t\t\t\t\u0026lt;SOFTIRQ\u0026gt;\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tbase-\u0026gt;running_timer = timer;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t[call_timer_fn enter]\n\t\t\t\t\tmod_timer()\n\t\t\t\t\t...\ntimer_shutdown_sync()\nlock_timer_base()\n// For now, will not detach the timer but only clear its function to NULL\nif (base-\u0026gt;running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer-\u0026gt;function = NULL;\nunlock_timer_base()\n\t\t\t\t\t[call_timer_fn exit]\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\tbase-\u0026gt;running_timer = NULL;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t...\n\t\t\t\t\t// Now timer is pending while its function set to NULL.\n\t\t\t\t\t// next timer trigger\n\t\t\t\t\t\u0026lt;SOFTIRQ\u0026gt;\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tWARN_ON_ONCE(!fn) // hit\n\t\t\t\t\t...\nlock_timer_base()\n// Now timer will detach\nif (base-\u0026gt;running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer-\u0026gt;function = NULL;\nunlock_timer_base()\n\nThe problem is that timer_shutdown_sync() clears the timer function\nregardless of whether the timer is currently running. This can leave a\npending timer with a NULL function pointer, which triggers the\nWARN_ON_ONCE(!fn) check in expire_timers().\n\nFix this by only clearing the timer function when actually detaching the\ntimer. If the timer is running, leave the function pointer intact, which is\nsafe because the timer will be properly detached when it finishes running.(CVE-2025-68214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: storage: Fix memory leak in USB bulk transport\n\nA kernel memory leak was identified by the \u0026apos;ioctl_sg01\u0026apos; test from Linux\nTest Project (LTP). The following bytes were mainly observed: 0x53425355.\n\nWhen USB storage devices incorrectly skip the data phase with status data,\nthe code extracts/validates the CSW from the sg buffer, but fails to clear\nit afterwards. This leaves status protocol data in srb\u0026apos;s transfer buffer,\nsuch as the US_BULK_CS_SIGN \u0026apos;USBS\u0026apos; signature observed here. Thus, this can\nlead to USB protocols leaks to user space through SCSI generic (/dev/sg*)\ninterfaces, such as the one seen here when the LTP test requested 512 KiB.\n\nFix the leak by zeroing the CSW data in srb\u0026apos;s transfer buffer immediately\nafter the validation of devices that skip data phase.\n\nNote: Differently from CVE-2018-1000204, which fixed a big leak by zero-\ning pages at allocation time, this leak occurs after allocation, when USB\nprotocol data is written to already-allocated sg pages.(CVE-2025-68288)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: xattr: fix null pointer deref in ext4_raw_inode()\n\nIf ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED),\niloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all()\nlacks error checking, this will lead to a null pointer dereference\nin ext4_raw_inode(), called right after ext4_get_inode_loc().\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68820)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: using the num_tqps in the vf driver to apply for resources\n\nCurrently, hdev-\u0026gt;htqp is allocated using hdev-\u0026gt;num_tqps, and kinfo-\u0026gt;tqp\nis allocated using kinfo-\u0026gt;num_tqps. However, kinfo-\u0026gt;num_tqps is set to\nmin(new_tqps, hdev-\u0026gt;num_tqps); Therefore, kinfo-\u0026gt;num_tqps may be smaller\nthan hdev-\u0026gt;num_tqps, which causes some hdev-\u0026gt;htqp[i] to remain\nuninitialized in hclgevf_knic_setup().\n\nThus, this patch allocates hdev-\u0026gt;htqp and kinfo-\u0026gt;tqp using hdev-\u0026gt;num_tqps,\nensuring that the lengths of hdev-\u0026gt;htqp and kinfo-\u0026gt;tqp are consistent\nand that all elements are properly initialized.(CVE-2025-71064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: observe an RCU grace period in macvlan_common_newlink() error path\n\nvalis reported that a race condition still happens after my prior patch.\n\nmacvlan_common_newlink() might have made @dev visible before\ndetecting an error, and its caller will directly call free_netdev(dev).\n\nWe must respect an RCU period, either in macvlan or the core networking\nstack.\n\nAfter adding a temporary mdelay(1000) in macvlan_forward_source_one()\nto open the race window, valis repro was:\n\nip link add p1 type veth peer p2\nip link set address 00:00:00:00:00:20 dev p1\nip link set up dev p1\nip link set up dev p2\nip link add mv0 link p2 type macvlan mode source\n\n(ip link add invalid% link p2 type macvlan mode source macaddr add\n00:00:00:00:00:20 \u0026amp;) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4\nPING 1.2.3.4 (1.2.3.4): 56 data bytes\nRTNETLINK answers: Invalid argument\n\nBUG: KASAN: slab-use-after-free in macvlan_forward_source\n(drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nRead of size 8 at addr ffff888016bb89c0 by task e/175\n\nCPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\nCall Trace:\n\u0026lt;IRQ\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:123)\nprint_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nkasan_report (mm/kasan/report.c:597)\n? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nmacvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\n? tasklet_init (kernel/softirq.c:983)\nmacvlan_handle_frame (drivers/net/macvlan.c:501)\n\nAllocated by task 169:\nkasan_save_stack (mm/kasan/common.c:58)\nkasan_save_track (./arch/x86/include/asm/current.h:25\nmm/kasan/common.c:70 mm/kasan/common.c:79)\n__kasan_kmalloc (mm/kasan/common.c:419)\n__kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5657\nmm/slub.c:7140)\nalloc_netdev_mqs (net/core/dev.c:12012)\nrtnl_create_link (net/core/rtnetlink.c:3648)\nrtnl_newlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957\nnet/core/rtnetlink.c:4072)\nrtnetlink_rcv_msg (net/core/rtnetlink.c:6958)\nnetlink_rcv_skb (net/netlink/af_netlink.c:2550)\nnetlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\nnetlink_sendmsg (net/netlink/af_netlink.c:1894)\n__sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)\n__x64_sys_sendto (net/socket.c:2209)\ndo_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)\n\nFreed by task 169:\nkasan_save_stack (mm/kasan/common.c:58)\nkasan_save_track (./arch/x86/include/asm/current.h:25\nmm/kasan/common.c:70 mm/kasan/common.c:79)\nkasan_save_free_info (mm/kasan/generic.c:587)\n__kasan_slab_free (mm/kasan/common.c:287)\nkfree (mm/slub.c:6674 mm/slub.c:6882)\nrtnl_newlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957\nnet/core/rtnetlink.c:4072)\nrtnetlink_rcv_msg (net/core/rtnetlink.c:6958)\nnetlink_rcv_skb (net/netlink/af_netlink.c:2550)\nnetlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\nnetlink_sendmsg (net/netlink/af_netlink.c:1894)\n__sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)\n__x64_sys_sendto (net/socket.c:2209)\ndo_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)(CVE-2026-23273)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access\n\nl2cap_information_rsp() checks that cmd_len covers the fixed\nl2cap_info_rsp header (type + result, 4 bytes) but then reads\nrsp-\u0026gt;data without verifying that the payload is present:\n\n - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp-\u0026gt;data), which reads\n 4 bytes past the header (needs cmd_len \u0026gt;= 8).\n\n - L2CAP_IT_FIXED_CHAN reads rsp-\u0026gt;data[0], 1 byte past the header\n (needs cmd_len \u0026gt;= 5).\n\nA truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an\nout-of-bounds read of adjacent skb data.\n\nGuard each data access with the required payload length check. If the\npayload is too short, skip the read and let the state machine complete\nwith safe defaults (feat_mask and remote_fixed_chan remain zero from\nkzalloc), so the info timer cleanup and l2cap_conn_start() still run\nand the connection is not stalled.(CVE-2026-31393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: reject mount if bigalloc with s_first_data_block != 0\n\nbigalloc with s_first_data_block != 0 is not supported, reject mounting\nit.(CVE-2026-31447)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix memory leaks and NULL deref in smb2_lock()\n\nsmb2_lock() has three error handling issues after list_del() detaches\nsmb_lock from lock_list at no_check_cl:\n\n1) If vfs_lock_file() returns an unexpected error in the non-UNLOCK\n path, goto out leaks smb_lock and its flock because the out:\n handler only iterates lock_list and rollback_list, neither of\n which contains the detached smb_lock.\n\n2) If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out\n leaks smb_lock and flock for the same reason. The error code\n returned to the dispatcher is also stale.\n\n3) In the rollback path, smb_flock_init() can return NULL on\n allocation failure. The result is dereferenced unconditionally,\n causing a kernel NULL pointer dereference. Add a NULL check to\n prevent the crash and clean up the bookkeeping; the VFS lock\n itself cannot be rolled back without the allocation and will be\n released at file or connection teardown.\n\nFix cases 1 and 2 by hoisting the locks_free_lock()/kfree() to before\nthe if(!rc) check in the UNLOCK branch so all exit paths share one\nfree site, and by freeing smb_lock and flock before goto out in the\nnon-UNLOCK branch. Propagate the correct error code in both cases.\nFix case 3 by wrapping the VFS unlock in an if(rlock) guard and adding\na NULL check for locks_free_lock(rlock) in the shared cleanup.\n\nFound via call-graph analysis using sqry.(CVE-2026-31477)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: platform: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus\u0026apos; match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-31527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: require 3 sub-authorities before reading sub_auth[2]\n\nparse_dacl() compares each ACE SID against sid_unix_NFS_mode and on\nmatch reads sid.sub_auth[2] as the file mode. If sid_unix_NFS_mode is\nthe prefix S-1-5-88-3 with num_subauth = 2 then compare_sids() compares\nonly min(num_subauth, 2) sub-authorities so a client SID with\nnum_subauth = 2 and sub_auth = {88, 3} will match.\n\nIf num_subauth = 2 and the ACE is placed at the very end of the security\ndescriptor, sub_auth[2] will be 4 bytes past end_of_acl. The\nout-of-band bytes will then be masked to the low 9 bits and applied as\nthe file\u0026apos;s POSIX mode, probably not something that is good to have\nhappen.\n\nFix this up by forcing the SID to actually carry a third sub-authority\nbefore reading it at all.(CVE-2026-31611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: validate EaNameLength in smb2_get_ea()\n\nsmb2_get_ea() reads ea_req-\u0026gt;EaNameLength from the client request and\npasses it directly to strncmp() as the comparison length without\nverifying that the length of the name really is the size of the input\nbuffer received.\n\nFix this up by properly checking the size of the name based on the value\nreceived and the overall size of the request, to prevent a later\nstrncmp() call to use the length as a \u0026quot;trusted\u0026quot; size of the buffer.\nWithout this check, uninitialized heap values might be slowly leaked to\nthe client.(CVE-2026-31612)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: use check_add_overflow() to prevent u16 DACL size overflow\n\nset_posix_acl_entries_dacl() and set_ntacl_dacl() accumulate ACE sizes\nin u16 variables. When a file has many POSIX ACL entries, the\naccumulated size can wrap past 65535, causing the pointer arithmetic\n(char *)pndace + *size to land within already-written ACEs. Subsequent\nwrites then overwrite earlier entries, and pndacl-\u0026gt;size gets a\ntruncated value.\n\nUse check_add_overflow() at each accumulation point to detect the\nwrap before it corrupts the buffer, consistent with existing\ncheck_mul_overflow() usage elsewhere in smbacl.c.(CVE-2026-31704)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path\n\nsmb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL\nand the default QUERY_INFO path. The QUERY_INFO branch clamps\nqi.input_buffer_length to the server-reported OutputBufferLength and then\ncopies qi.input_buffer_length bytes from qi_rsp-\u0026gt;Buffer to userspace, but\nit never verifies that the flexible-array payload actually fits within\nrsp_iov[1].iov_len.\n\nA malicious server can return OutputBufferLength larger than the actual\nQUERY_INFO response, causing copy_to_user() to walk past the response\nbuffer and expose adjacent kernel heap to userspace.\n\nGuard the QUERY_INFO copy with a bounds check on the actual Buffer\npayload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length)\nrather than an open-coded addition so the guard cannot overflow on\n32-bit builds.(CVE-2026-31708)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: gadget: fix state inconsistency on gadget init failure\n\nWhen cdns3_gadget_start() fails, the DRD hardware is left in gadget mode\nwhile software state remains INACTIVE, creating hardware/software state\ninconsistency.\n\nWhen switching to host mode via sysfs:\n echo host \u0026gt; /sys/class/usb_role/13180000.usb-role-switch/role\n\nThe role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error,\nso cdns_role_stop() skips cleanup because state is still INACTIVE.\nThis violates the DRD controller design specification (Figure22),\nwhich requires returning to idle state before switching roles.\n\nThis leads to a synchronous external abort in xhci_gen_setup() when\nsetting up the host controller:\n\n[ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19\n[ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget\n[ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed\n...\n[ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller\n[ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP\n[ 1301.382485] pc : xhci_gen_setup+0xa4/0x408\n[ 1301.393391] backtrace:\n ...\n xhci_gen_setup+0xa4/0x408 \u0026lt;-- CRASH\n xhci_plat_setup+0x44/0x58\n usb_add_hcd+0x284/0x678\n ...\n cdns_role_set+0x9c/0xbc \u0026lt;-- Role switch\n\nFix by calling cdns_drd_gadget_off() in the error path to properly\nclean up the DRD gadget state.(CVE-2026-31754)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: gadget: fix NULL pointer dereference in ep_queue\n\nWhen the gadget endpoint is disabled or not yet configured, the ep-\u0026gt;desc\npointer can be NULL. This leads to a NULL pointer dereference when\n__cdns3_gadget_ep_queue() is called, causing a kernel crash.\n\nAdd a check to return -ESHUTDOWN if ep-\u0026gt;desc is NULL, which is the\nstandard return code for unconfigured endpoints.\n\nThis prevents potential crashes when ep_queue is called on endpoints\nthat are not ready.(CVE-2026-31755)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: move wake reason storage into validated event handlers\n\nhci_store_wake_reason() is called from hci_event_packet() immediately\nafter stripping the HCI event header but before hci_event_func()\nenforces the per-event minimum payload length from hci_ev_table.\nThis means a short HCI event frame can reach bacpy() before any bounds\ncheck runs.\n\nRather than duplicating skb parsing and per-event length checks inside\nhci_store_wake_reason(), move wake-address storage into the individual\nevent handlers after their existing event-length validation has\nsucceeded. Convert hci_store_wake_reason() into a small helper that only\nstores an already-validated bdaddr while the caller holds hci_dev_lock().\nUse the same helper after hci_event_func() with a NULL address to\npreserve the existing unexpected-wake fallback semantics when no\nvalidated event handler records a wake address.\n\nAnnotate the helper with __must_hold(\u0026amp;hdev-\u0026gt;lock) and add\nlockdep_assert_held(\u0026amp;hdev-\u0026gt;lock) so future call paths keep the lock\ncontract explicit.\n\nCall the helper from hci_conn_request_evt(), hci_conn_complete_evt(),\nhci_sync_conn_complete_evt(), le_conn_complete_evt(),\nhci_le_adv_report_evt(), hci_le_ext_adv_report_evt(),\nhci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), and\nhci_le_past_received_evt().(CVE-2026-31771)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Check to ensure report responses match the request\n\nIt is possible for a malicious (or clumsy) device to respond to a\nspecific report\u0026apos;s feature request using a completely different report\nID. This can cause confusion in the HID core resulting in nasty\nside-effects such as OOB writes.\n\nAdd a check to ensure that the report ID in the response, matches the\none that was requested. If it doesn\u0026apos;t, omit reporting the raw event and\nreturn early.(CVE-2026-43047)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Mitigate potential OOB by removing bogus memset()\n\nThe memset() in hid_report_raw_event() has the good intention of\nclearing out bogus data by zeroing the area from the end of the incoming\ndata string to the assumed end of the buffer. However, as we have\npreviously seen, doing so can easily result in OOB reads and writes in\nthe subsequent thread of execution.\n\nThe current suggestion from one of the HID maintainers is to remove the\nmemset() and simply return if the incoming event buffer size is not\nlarge enough to fill the associated report.\n\nSuggested-by Benjamin Tissoires \u0026lt;(CVE-2026-43048)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nEFI/CPER: don\u0026apos;t dump the entire memory region\n\nThe current logic at cper_print_fw_err() doesn\u0026apos;t check if the\nerror record length is big enough to handle offset. On a bad firmware,\nif the ofset is above the actual record, length -= offset will\nunderflow, making it dump the entire memory.\n\nThe end result can be:\n\n - the logic taking a lot of time dumping large regions of memory;\n - data disclosure due to the memory dumps;\n - an OOPS, if it tries to dump an unmapped memory region.\n\nFix it by checking if the section length is too small before doing\na hex dump.\n\n[ rjw: Subject tweaks ](CVE-2026-43171)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE\n\nThe arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE -\nwhich is a valid index - so add a check for this.(CVE-2026-43212)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: Add support for TSV110 Spectre-BHB mitigation\n\nThe TSV110 processor is vulnerable to the Spectre-BHB (Branch History\nBuffer) attack, which can be exploited to leak information through\nbranch prediction side channels. This commit adds the MIDR of TSV110\nto the list for software mitigation.(CVE-2026-43261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Limit the length of unkillable synchronous timeouts\n\nThe usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device.\n\nTo prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel\u0026apos;s hung-task detector.\n\nIn addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.(CVE-2026-43428)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Prevent interrupt storm on host controller error (HCE)\n\nThe xHCI controller reports a Host Controller Error (HCE) in UAS Storage\nDevice plug/unplug scenarios on Android devices. HCE is checked in\nxhci_irq() function and causes an interrupt storm (since the interrupt\nisn\u2019t cleared), leading to severe system-level faults.\n\nWhen the xHC controller reports HCE in the interrupt handler, the driver\nonly logs a warning and assumes xHC activity will stop as stated in xHCI\nspecification. An interrupt storm does however continue on some hosts\neven after HCE, and only ceases after manually disabling xHC interrupt\nand stopping the controller by calling xhci_halt().\n\nAdd xhci_halt() to xhci_irq() function where STS_HCE status is checked,\nmirroring the existing error handling pattern used for STS_FATAL errors.\n\nThis only fixes the interrupt storm. Proper HCE recovery requires resetting\nand re-initializing the xHC.(CVE-2026-43488)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nptrace: slightly saner \u0026apos;get_dumpable()\u0026apos; logic\n\nThe \u0026apos;dumpability\u0026apos; of a task is fundamentally about the memory image of\nthe task - the concept comes from whether it can core dump or not - and\nmakes no sense when you don\u0026apos;t have an associated mm.\n\nAnd almost all users do in fact use it only for the case where the task\nhas a mm pointer.\n\nBut we have one odd special case: ptrace_may_access() uses \u0026apos;dumpable\u0026apos; to\ncheck various other things entirely independently of the MM (typically\nexplicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for\nthreads that no longer have a VM (and maybe never did, like most kernel\nthreads).\n\nIt\u0026apos;s not what this flag was designed for, but it is what it is.\n\nThe ptrace code does check that the uid/gid matches, so you do have to\nbe uid-0 to see kernel thread details, but this means that the\ntraditional \u0026quot;drop capabilities\u0026quot; model doesn\u0026apos;t make any difference for\nthis all.\n\nMake it all make a *bit* more sense by saying that if you don\u0026apos;t have a\nMM pointer, we\u0026apos;ll use a cached \u0026quot;last dumpability\u0026quot; flag if the thread\never had a MM (it will be zero for kernel threads since it is never\nset), and require a proper CAP_SYS_PTRACE capability to override.(CVE-2026-46333)",
"id": "OESA-2026-2416",
"modified": "2026-08-06T11:11:22Z",
"published": "2026-05-22T11:11:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2416"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38488"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39841"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40261"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40324"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68185"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68288"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68820"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71064"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23273"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31447"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31477"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31527"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31611"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31612"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31704"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31708"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31754"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31755"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31771"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43047"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43048"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43171"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43212"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43261"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43428"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43488"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46333"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-38488",
"CVE-2025-39841",
"CVE-2025-40261",
"CVE-2025-40324",
"CVE-2025-68185",
"CVE-2025-68214",
"CVE-2025-68288",
"CVE-2025-68820",
"CVE-2025-71064",
"CVE-2026-23273",
"CVE-2026-31393",
"CVE-2026-31447",
"CVE-2026-31477",
"CVE-2026-31527",
"CVE-2026-31611",
"CVE-2026-31612",
"CVE-2026-31704",
"CVE-2026-31708",
"CVE-2026-31754",
"CVE-2026-31755",
"CVE-2026-31771",
"CVE-2026-43047",
"CVE-2026-43048",
"CVE-2026-43171",
"CVE-2026-43212",
"CVE-2026-43261",
"CVE-2026-43428",
"CVE-2026-43488",
"CVE-2026-46333"
]
}
OESA-2026-2419 (CVE-2026-31393)
Vulnerability from osv_openeuler – Published: 2026-05-22 11:11 – Updated: 2026-08-06 11:11 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access
l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present:
-
L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8).
-
L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5).
A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data.
Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.(CVE-2026-31393)
In the Linux kernel, the following vulnerability has been resolved:
ext4: reject mount if bigalloc with s_first_data_block != 0
bigalloc with s_first_data_block != 0 is not supported, reject mounting it.(CVE-2026-31447)
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: Check to ensure report responses match the request
It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes.
Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.(CVE-2026-43047)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: Mitigate potential OOB by removing bogus memset()
The memset() in hid_report_raw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution.
The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report.
Suggested-by Benjamin Tissoires <(CVE-2026-43048)
In the Linux kernel, there is a potential out-of-bounds access vulnerability in the ceph_handle_auth_reply() function of the libceph component. When processing messages of type CEPH_MSG_AUTH_REPLY, the value of the payload_len field is stored in a variable of type int. A value greater than INT_MAX leads to integer overflow and is interpreted as a negative value, which causes the pointer address to be decremented and subsequently accessed because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. The vulnerability is fixed by changing the data type of payload_len to u32 and introducing additional sanity checks.(CVE-2026-43407)
| URL | Type | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"kernel-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"kernel-debugsource-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"kernel-devel-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"kernel-extra-modules-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"kernel-headers-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"kernel-source-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"kernel-tools-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"perf-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"perf-debuginfo-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"python3-perf-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.3.12.142.oe2403sp3.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.3.12.142.oe2403sp3.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"kernel-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"kernel-debugsource-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"kernel-devel-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"kernel-extra-modules-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"kernel-headers-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"kernel-source-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"kernel-tools-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"perf-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"perf-debuginfo-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"python3-perf-6.6.0-145.3.12.142.oe2403sp3.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.3.12.142.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.12.142.oe2403sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access\n\nl2cap_information_rsp() checks that cmd_len covers the fixed\nl2cap_info_rsp header (type + result, 4 bytes) but then reads\nrsp-\u0026gt;data without verifying that the payload is present:\n\n - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp-\u0026gt;data), which reads\n 4 bytes past the header (needs cmd_len \u0026gt;= 8).\n\n - L2CAP_IT_FIXED_CHAN reads rsp-\u0026gt;data[0], 1 byte past the header\n (needs cmd_len \u0026gt;= 5).\n\nA truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an\nout-of-bounds read of adjacent skb data.\n\nGuard each data access with the required payload length check. If the\npayload is too short, skip the read and let the state machine complete\nwith safe defaults (feat_mask and remote_fixed_chan remain zero from\nkzalloc), so the info timer cleanup and l2cap_conn_start() still run\nand the connection is not stalled.(CVE-2026-31393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: reject mount if bigalloc with s_first_data_block != 0\n\nbigalloc with s_first_data_block != 0 is not supported, reject mounting\nit.(CVE-2026-31447)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Check to ensure report responses match the request\n\nIt is possible for a malicious (or clumsy) device to respond to a\nspecific report\u0026apos;s feature request using a completely different report\nID. This can cause confusion in the HID core resulting in nasty\nside-effects such as OOB writes.\n\nAdd a check to ensure that the report ID in the response, matches the\none that was requested. If it doesn\u0026apos;t, omit reporting the raw event and\nreturn early.(CVE-2026-43047)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Mitigate potential OOB by removing bogus memset()\n\nThe memset() in hid_report_raw_event() has the good intention of\nclearing out bogus data by zeroing the area from the end of the incoming\ndata string to the assumed end of the buffer. However, as we have\npreviously seen, doing so can easily result in OOB reads and writes in\nthe subsequent thread of execution.\n\nThe current suggestion from one of the HID maintainers is to remove the\nmemset() and simply return if the incoming event buffer size is not\nlarge enough to fill the associated report.\n\nSuggested-by Benjamin Tissoires \u0026lt;(CVE-2026-43048)\n\nIn the Linux kernel, there is a potential out-of-bounds access vulnerability in the ceph_handle_auth_reply() function of the libceph component. When processing messages of type CEPH_MSG_AUTH_REPLY, the value of the payload_len field is stored in a variable of type int. A value greater than INT_MAX leads to integer overflow and is interpreted as a negative value, which causes the pointer address to be decremented and subsequently accessed because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. The vulnerability is fixed by changing the data type of payload_len to u32 and introducing additional sanity checks.(CVE-2026-43407)",
"id": "OESA-2026-2419",
"modified": "2026-08-06T11:11:22Z",
"published": "2026-05-22T11:11:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2419"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31447"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43047"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43048"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43407"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2026-31393",
"CVE-2026-31447",
"CVE-2026-43047",
"CVE-2026-43048",
"CVE-2026-43407"
]
}
OPENSUSE-SU-2026:20826-1
Vulnerability from csaf_opensuse - Published: 2026-05-28 12:58 - Updated: 2026-09-17 17:33SUSE-SU-2026:2068-1
Vulnerability from csaf_suse - Published: 2026-05-26 07:29 - Updated: 2026-09-16 19:34Sightings
| 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.