Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-71089 (GCVE-0-2025-71089)
Vulnerability from cvelistv5 – Published: 2026-01-13 15:34 – Updated: 2026-08-05 12:11| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
26b25a2b98e45aeb40eedcedc586ad5034cbd984 , < b34289505180a83607fcfdce14b5a290d0528476
(git)
Affected: 26b25a2b98e45aeb40eedcedc586ad5034cbd984 , < 7cad37e358970af1bb49030ff01f06a69fa7d985 (git) Affected: 26b25a2b98e45aeb40eedcedc586ad5034cbd984 , < 240cd7f2812cc25496b12063d11c823618f364e9 (git) Affected: 26b25a2b98e45aeb40eedcedc586ad5034cbd984 , < c2c3f1a3fd74ef16cf115f0c558616a13a8471b4 (git) Affected: 26b25a2b98e45aeb40eedcedc586ad5034cbd984 , < c341dee80b5df49a936182341b36395c831c2661 (git) Affected: 26b25a2b98e45aeb40eedcedc586ad5034cbd984 , < 72f98ef9a4be30d2a60136dd6faee376f780d06c (git) |
guessed | |
| Linux | Linux |
Affected:
5.2
Unaffected: 0 , < 5.2 (semver) Unaffected: 5.15.200 , ≤ 5.15.* (semver) Unaffected: 6.1.163 , ≤ 6.1.* (semver) Unaffected: 6.6.120 , ≤ 6.6.* (semver) Unaffected: 6.12.64 , ≤ 6.12.* (semver) Unaffected: 6.18.4 , ≤ 6.18.* (semver) Unaffected: 6.19 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-71089",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-16T16:19:59.752068Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-16T16:20:14.545Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/iommu/iommu-sva.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b34289505180a83607fcfdce14b5a290d0528476",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "7cad37e358970af1bb49030ff01f06a69fa7d985",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "240cd7f2812cc25496b12063d11c823618f364e9",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "c2c3f1a3fd74ef16cf115f0c558616a13a8471b4",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "c341dee80b5df49a936182341b36395c831c2661",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "72f98ef9a4be30d2a60136dd6faee376f780d06c",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/iommu/iommu-sva.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.200",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.163",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.200",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.163",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.120",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.64",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.4",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19",
"versionStartIncluding": "5.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu: disable SVA when CONFIG_X86 is set\n\nPatch series \"Fix stale IOTLB entries for kernel address space\", v7.\n\nThis proposes a fix for a security vulnerability related to IOMMU Shared\nVirtual Addressing (SVA). In an SVA context, an IOMMU can cache kernel\npage table entries. When a kernel page table page is freed and\nreallocated for another purpose, the IOMMU might still hold stale,\nincorrect entries. This can be exploited to cause a use-after-free or\nwrite-after-free condition, potentially leading to privilege escalation or\ndata corruption.\n\nThis solution introduces a deferred freeing mechanism for kernel page\ntable pages, which provides a safe window to notify the IOMMU to\ninvalidate its caches before the page is reused.\n\n\nThis patch (of 8):\n\nIn the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware\nshares and walks the CPU\u0027s page tables. The x86 architecture maps the\nkernel\u0027s virtual address space into the upper portion of every process\u0027s\npage table. Consequently, in an SVA context, the IOMMU hardware can walk\nand cache kernel page table entries.\n\nThe Linux kernel currently lacks a notification mechanism for kernel page\ntable changes, specifically when page table pages are freed and reused. \nThe IOMMU driver is only notified of changes to user virtual address\nmappings. This can cause the IOMMU\u0027s internal caches to retain stale\nentries for kernel VA.\n\nUse-After-Free (UAF) and Write-After-Free (WAF) conditions arise when\nkernel page table pages are freed and later reallocated. The IOMMU could\nmisinterpret the new data as valid page table entries. The IOMMU might\nthen walk into attacker-controlled memory, leading to arbitrary physical\nmemory DMA access or privilege escalation. This is also a\nWrite-After-Free issue, as the IOMMU will potentially continue to write\nAccessed and Dirty bits to the freed memory while attempting to walk the\nstale page tables.\n\nCurrently, SVA contexts are unprivileged and cannot access kernel\nmappings. However, the IOMMU will still walk kernel-only page tables all\nthe way down to the leaf entries, where it realizes the mapping is for the\nkernel and errors out. This means the IOMMU still caches these\nintermediate page table entries, making the described vulnerability a real\nconcern.\n\nDisable SVA on x86 architecture until the IOMMU can receive notification\nto flush the paging cache before freeing the CPU kernel page table pages."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "IOMMU SVA stale kernel page table entries enable arbitrary physical memory DMA access. IOMMU caches kernel page table entries that become stale when freed and reallocated, allowing walk into attacker-controlled memory. Scope Changed as it breaks IOMMU hardware isolation boundary."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T12:11:58.679Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/b34289505180a83607fcfdce14b5a290d0528476"
},
{
"url": "https://git.kernel.org/stable/c/7cad37e358970af1bb49030ff01f06a69fa7d985"
},
{
"url": "https://git.kernel.org/stable/c/240cd7f2812cc25496b12063d11c823618f364e9"
},
{
"url": "https://git.kernel.org/stable/c/c2c3f1a3fd74ef16cf115f0c558616a13a8471b4"
},
{
"url": "https://git.kernel.org/stable/c/c341dee80b5df49a936182341b36395c831c2661"
},
{
"url": "https://git.kernel.org/stable/c/72f98ef9a4be30d2a60136dd6faee376f780d06c"
}
],
"title": "iommu: disable SVA when CONFIG_X86 is set",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-71089",
"datePublished": "2026-01-13T15:34:51.079Z",
"dateReserved": "2026-01-13T15:30:19.649Z",
"dateUpdated": "2026-08-05T12:11:58.679Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-71089",
"date": "2026-09-27",
"epss": "0.00165",
"percentile": "0.05044"
},
"microsoft_vex": {
"current_release_date": "2026-03-03T01:39:11.000Z",
"cve": "CVE-2025-71089",
"id": "msrc_CVE-2025-71089",
"initial_release_date": "2026-01-02T00:00:00.000Z",
"product_status:fixed": "1",
"product_status:known_affected": "2",
"product_status:known_not_affected": "1",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "iommu: disable SVA when CONFIG_X86 is set",
"url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2025-71089.json",
"version": "5"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/iommu/iommu-sva.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b34289505180a83607fcfdce14b5a290d0528476",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "7cad37e358970af1bb49030ff01f06a69fa7d985",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "240cd7f2812cc25496b12063d11c823618f364e9",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "c2c3f1a3fd74ef16cf115f0c558616a13a8471b4",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "c341dee80b5df49a936182341b36395c831c2661",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "72f98ef9a4be30d2a60136dd6faee376f780d06c",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/iommu/iommu-sva.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.200",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.163",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E5B74AED-8F4D-46D6-9567-2309ADEA5E74",
"versionEndExcluding": "5.15.200",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E9C856E1-4308-4C0B-A973-7DD375DF66C4",
"versionEndExcluding": "6.1.163",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "43C3A206-5EEE-417B-AA0F-EF8972E7A9F0",
"versionEndExcluding": "6.6.120",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "32BF4A52-377C-44ED-B5E6-7EA5D896E98B",
"versionEndExcluding": "6.12.64",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "DC988EA0-0E32-457A-BF95-89BEB31A227B",
"versionEndExcluding": "6.18.4",
"versionStartIncluding": "6.13",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu: disable SVA when CONFIG_X86 is set\n\nPatch series \"Fix stale IOTLB entries for kernel address space\", v7.\n\nThis proposes a fix for a security vulnerability related to IOMMU Shared\nVirtual Addressing (SVA). In an SVA context, an IOMMU can cache kernel\npage table entries. When a kernel page table page is freed and\nreallocated for another purpose, the IOMMU might still hold stale,\nincorrect entries. This can be exploited to cause a use-after-free or\nwrite-after-free condition, potentially leading to privilege escalation or\ndata corruption.\n\nThis solution introduces a deferred freeing mechanism for kernel page\ntable pages, which provides a safe window to notify the IOMMU to\ninvalidate its caches before the page is reused.\n\n\nThis patch (of 8):\n\nIn the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware\nshares and walks the CPU\u0027s page tables. The x86 architecture maps the\nkernel\u0027s virtual address space into the upper portion of every process\u0027s\npage table. Consequently, in an SVA context, the IOMMU hardware can walk\nand cache kernel page table entries.\n\nThe Linux kernel currently lacks a notification mechanism for kernel page\ntable changes, specifically when page table pages are freed and reused. \nThe IOMMU driver is only notified of changes to user virtual address\nmappings. This can cause the IOMMU\u0027s internal caches to retain stale\nentries for kernel VA.\n\nUse-After-Free (UAF) and Write-After-Free (WAF) conditions arise when\nkernel page table pages are freed and later reallocated. The IOMMU could\nmisinterpret the new data as valid page table entries. The IOMMU might\nthen walk into attacker-controlled memory, leading to arbitrary physical\nmemory DMA access or privilege escalation. This is also a\nWrite-After-Free issue, as the IOMMU will potentially continue to write\nAccessed and Dirty bits to the freed memory while attempting to walk the\nstale page tables.\n\nCurrently, SVA contexts are unprivileged and cannot access kernel\nmappings. However, the IOMMU will still walk kernel-only page tables all\nthe way down to the leaf entries, where it realizes the mapping is for the\nkernel and errors out. This means the IOMMU still caches these\nintermediate page table entries, making the described vulnerability a real\nconcern.\n\nDisable SVA on x86 architecture until the IOMMU can receive notification\nto flush the paging cache before freeing the CPU kernel page table pages."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\niommu: deshabilitar SVA cuando CONFIG_X86 est\u00e1 configurado\n\nSerie de parches \u0027Correcci\u00f3n de entradas IOTLB obsoletas para el espacio de direcciones del kernel\u0027, v7.\n\nEsto propone una correcci\u00f3n para una vulnerabilidad de seguridad relacionada con el Direccionamiento Virtual Compartido (SVA) de IOMMU. En un contexto SVA, un IOMMU puede almacenar en cach\u00e9 entradas de la tabla de p\u00e1ginas del kernel. Cuando una p\u00e1gina de la tabla de p\u00e1ginas del kernel es liberada y reasignada para otro prop\u00f3sito, el IOMMU a\u00fan podr\u00eda contener entradas obsoletas e incorrectas. Esto puede ser explotado para causar una condici\u00f3n de uso despu\u00e9s de liberaci\u00f3n o de escritura despu\u00e9s de liberaci\u00f3n, lo que podr\u00eda llevar a una escalada de privilegios o a la corrupci\u00f3n de datos.\n\nEsta soluci\u00f3n introduce un mecanismo de liberaci\u00f3n diferida para las p\u00e1ginas de la tabla de p\u00e1ginas del kernel, que proporciona una ventana segura para notificar al IOMMU que invalide sus cach\u00e9s antes de que la p\u00e1gina sea reutilizada.\n\nEste parche (de 8):\n\nEn el contexto de Direccionamiento Virtual Compartido (SVA) de IOMMU, el hardware IOMMU comparte y recorre las tablas de p\u00e1ginas de la CPU. La arquitectura x86 mapea el espacio de direcciones virtual del kernel en la porci\u00f3n superior de la tabla de p\u00e1ginas de cada proceso. En consecuencia, en un contexto SVA, el hardware IOMMU puede recorrer y almacenar en cach\u00e9 entradas de la tabla de p\u00e1ginas del kernel.\n\nEl kernel de Linux actualmente carece de un mecanismo de notificaci\u00f3n para los cambios en la tabla de p\u00e1ginas del kernel, espec\u00edficamente cuando las p\u00e1ginas de la tabla de p\u00e1ginas son liberadas y reutilizadas. El controlador IOMMU solo es notificado de los cambios en las asignaciones de direcciones virtuales de usuario. Esto puede hacer que las cach\u00e9s internas del IOMMU retengan entradas obsoletas para VA del kernel.\n\nLas condiciones de Uso Despu\u00e9s de Liberaci\u00f3n (UAF) y Escritura Despu\u00e9s de Liberaci\u00f3n (WAF) surgen cuando las p\u00e1ginas de la tabla de p\u00e1ginas del kernel son liberadas y posteriormente reasignadas. El IOMMU podr\u00eda malinterpretar los nuevos datos como entradas v\u00e1lidas de la tabla de p\u00e1ginas. El IOMMU podr\u00eda entonces recorrer memoria controlada por el atacante, lo que llevar\u00eda a un acceso DMA arbitrario a la memoria f\u00edsica o a una escalada de privilegios. Esto tambi\u00e9n es un problema de Escritura Despu\u00e9s de Liberaci\u00f3n, ya que el IOMMU potencialmente continuar\u00e1 escribiendo bits de Acceso y Sucio en la memoria liberada mientras intenta recorrer las tablas de p\u00e1ginas obsoletas.\n\nActualmente, los contextos SVA no tienen privilegios y no pueden acceder a las asignaciones del kernel. Sin embargo, el IOMMU seguir\u00e1 recorriendo tablas de p\u00e1ginas solo del kernel hasta las entradas hoja, donde se da cuenta de que la asignaci\u00f3n es para el kernel y produce un error. Esto significa que el IOMMU a\u00fan almacena en cach\u00e9 estas entradas intermedias de la tabla de p\u00e1ginas, lo que convierte la vulnerabilidad descrita en una preocupaci\u00f3n real.\n\nDeshabilitar SVA en la arquitectura x86 hasta que el IOMMU pueda recibir notificaci\u00f3n para vaciar la cach\u00e9 de paginaci\u00f3n antes de liberar las p\u00e1ginas de la tabla de p\u00e1ginas del kernel de la CPU."
}
],
"id": "CVE-2025-71089",
"lastModified": "2026-06-17T10:03:38.367",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.1,
"impactScore": 6.0,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-71089",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-16T16:19:59.752068Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-01-13T16:16:08.583",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/240cd7f2812cc25496b12063d11c823618f364e9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/72f98ef9a4be30d2a60136dd6faee376f780d06c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7cad37e358970af1bb49030ff01f06a69fa7d985"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b34289505180a83607fcfdce14b5a290d0528476"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c2c3f1a3fd74ef16cf115f0c558616a13a8471b4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c341dee80b5df49a936182341b36395c831c2661"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-08-21T20:05:26+00:00",
"cve": "CVE-2025-71089",
"id": "CVE-2025-71089",
"initial_release_date": "2025-01-01T00:00:00+00:00",
"product_status:fixed": "1671",
"product_status:known_affected": "98",
"product_status:known_not_affected": "42",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: iommu: disable SVA when CONFIG_X86 is set",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-71089.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "important",
"current_release_date": "2026-09-23T00:32:05Z",
"cve": "CVE-2025-71089",
"id": "CVE-2025-71089",
"initial_release_date": "2026-01-14T00:25:35Z",
"product_status:first_fixed": "2",
"product_status:known_affected": "427",
"product_status:known_not_affected": "153",
"product_status:recommended": "734",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2025-71089",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2025-71089.json",
"version": "50"
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-71089",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-16T16:19:59.752068Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-16T16:20:08.834Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/iommu/iommu-sva.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b34289505180a83607fcfdce14b5a290d0528476",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "7cad37e358970af1bb49030ff01f06a69fa7d985",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "240cd7f2812cc25496b12063d11c823618f364e9",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "c2c3f1a3fd74ef16cf115f0c558616a13a8471b4",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "c341dee80b5df49a936182341b36395c831c2661",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "72f98ef9a4be30d2a60136dd6faee376f780d06c",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/iommu/iommu-sva.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.200",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.163",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.200",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.163",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.120",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.64",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.4",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19",
"versionStartIncluding": "5.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu: disable SVA when CONFIG_X86 is set\n\nPatch series \"Fix stale IOTLB entries for kernel address space\", v7.\n\nThis proposes a fix for a security vulnerability related to IOMMU Shared\nVirtual Addressing (SVA). In an SVA context, an IOMMU can cache kernel\npage table entries. When a kernel page table page is freed and\nreallocated for another purpose, the IOMMU might still hold stale,\nincorrect entries. This can be exploited to cause a use-after-free or\nwrite-after-free condition, potentially leading to privilege escalation or\ndata corruption.\n\nThis solution introduces a deferred freeing mechanism for kernel page\ntable pages, which provides a safe window to notify the IOMMU to\ninvalidate its caches before the page is reused.\n\n\nThis patch (of 8):\n\nIn the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware\nshares and walks the CPU\u0027s page tables. The x86 architecture maps the\nkernel\u0027s virtual address space into the upper portion of every process\u0027s\npage table. Consequently, in an SVA context, the IOMMU hardware can walk\nand cache kernel page table entries.\n\nThe Linux kernel currently lacks a notification mechanism for kernel page\ntable changes, specifically when page table pages are freed and reused. \nThe IOMMU driver is only notified of changes to user virtual address\nmappings. This can cause the IOMMU\u0027s internal caches to retain stale\nentries for kernel VA.\n\nUse-After-Free (UAF) and Write-After-Free (WAF) conditions arise when\nkernel page table pages are freed and later reallocated. The IOMMU could\nmisinterpret the new data as valid page table entries. The IOMMU might\nthen walk into attacker-controlled memory, leading to arbitrary physical\nmemory DMA access or privilege escalation. This is also a\nWrite-After-Free issue, as the IOMMU will potentially continue to write\nAccessed and Dirty bits to the freed memory while attempting to walk the\nstale page tables.\n\nCurrently, SVA contexts are unprivileged and cannot access kernel\nmappings. However, the IOMMU will still walk kernel-only page tables all\nthe way down to the leaf entries, where it realizes the mapping is for the\nkernel and errors out. This means the IOMMU still caches these\nintermediate page table entries, making the described vulnerability a real\nconcern.\n\nDisable SVA on x86 architecture until the IOMMU can receive notification\nto flush the paging cache before freeing the CPU kernel page table pages."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T21:54:31.972Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/b34289505180a83607fcfdce14b5a290d0528476"
},
{
"url": "https://git.kernel.org/stable/c/7cad37e358970af1bb49030ff01f06a69fa7d985"
},
{
"url": "https://git.kernel.org/stable/c/240cd7f2812cc25496b12063d11c823618f364e9"
},
{
"url": "https://git.kernel.org/stable/c/c2c3f1a3fd74ef16cf115f0c558616a13a8471b4"
},
{
"url": "https://git.kernel.org/stable/c/c341dee80b5df49a936182341b36395c831c2661"
},
{
"url": "https://git.kernel.org/stable/c/72f98ef9a4be30d2a60136dd6faee376f780d06c"
}
],
"title": "iommu: disable SVA when CONFIG_X86 is set",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-71089",
"datePublished": "2026-01-13T15:34:51.079Z",
"dateReserved": "2026-01-13T15:30:19.649Z",
"dateUpdated": "2026-06-16T16:20:14.545Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2026-AVI-0956
Vulnerability from certfr_avis - Published: 2026-07-31 - Updated: 2026-07-31
De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un attaquant de provoquer une atteinte à la confidentialité des données, une atteinte à l'intégrité des données et un contournement de la politique de sécurité.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| SUSE | SUSE Linux Enterprise High Performance Computing | SUSE Linux Enterprise High Performance Computing 15 SP5 | ||
| SUSE | openSUSE Leap | openSUSE Leap 15.5 | ||
| SUSE | SUSE Linux Enterprise Live Patching | SUSE Linux Enterprise Live Patching 15-SP5 | ||
| SUSE | SUSE Linux Enterprise Real Time | SUSE Linux Enterprise Real Time 15 SP7 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server 16.0 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server for SAP Applications 15 SP6 | ||
| SUSE | SUSE Linux Enterprise High Performance Computing | SUSE Linux Enterprise High Performance Computing 12 SP5 | ||
| SUSE | SUSE Linux Enterprise High Performance Computing | SUSE Linux Enterprise High Performance Computing 15 SP4 | ||
| SUSE | SUSE Linux Enterprise Live Patching | SUSE Linux Enterprise Live Patching 12-SP5 | ||
| SUSE | openSUSE Leap | openSUSE Leap 15.4 | ||
| SUSE | SUSE Linux Enterprise Live Patching | SUSE Linux Enterprise Live Patching 15-SP6 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server for SAP Applications 12 SP5 | ||
| SUSE | SUSE Linux Enterprise Live Patching | SUSE Linux Enterprise Live Patching 15-SP7 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server 12 SP5 | ||
| SUSE | SUSE Linux Enterprise High Availability Extension | SUSE Linux Enterprise Server High Availability Extension 16.0 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server 15 SP5 | ||
| SUSE | SUSE Linux Micro Extras | SUSE Linux Micro Extras 6.1 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server for SAP Applications 15 SP5 | ||
| SUSE | openSUSE Leap | openSUSE Leap 15.6 | ||
| SUSE | SUSE Linux Enterprise Micro | SUSE Linux Enterprise Micro 5.3 | ||
| SUSE | SUSE Linux Enterprise Real Time | SUSE Linux Enterprise Real Time 15 SP5 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server for SAP applications 16.0 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server 15 SP6 | ||
| SUSE | SUSE Linux Enterprise Real Time | SUSE Linux Enterprise Real Time 15 SP4 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server for SAP Applications 15 SP7 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server for SAP Applications 15 SP4 | ||
| SUSE | SUSE Linux Enterprise Micro | SUSE Linux Enterprise Micro 5.5 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server 15 SP4 | ||
| SUSE | SUSE Linux Enterprise Real Time | SUSE Linux Enterprise Real Time 15 SP6 | ||
| SUSE | SUSE Linux Micro | SUSE Linux Micro 6.1 | ||
| SUSE | SUSE Linux Micro | SUSE Linux Micro 6.0 | ||
| SUSE | SUSE Linux Enterprise Server | SUSE Linux Enterprise Server 15 SP7 | ||
| SUSE | SUSE Linux Enterprise Micro | SUSE Linux Enterprise Micro 5.4 | ||
| SUSE | SUSE Linux Enterprise Live Patching | SUSE Linux Enterprise Live Patching 15-SP4 | ||
| SUSE | SUSE Linux Micro Extras | SUSE Linux Micro Extras 6.0 |
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP5",
"product": {
"name": "SUSE Linux Enterprise High Performance Computing",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.5",
"product": {
"name": "openSUSE Leap",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP5",
"product": {
"name": "SUSE Linux Enterprise Live Patching",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP7",
"product": {
"name": "SUSE Linux Enterprise Real Time",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 16.0",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP6",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 12 SP5",
"product": {
"name": "SUSE Linux Enterprise High Performance Computing",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP4",
"product": {
"name": "SUSE Linux Enterprise High Performance Computing",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 12-SP5",
"product": {
"name": "SUSE Linux Enterprise Live Patching",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.4",
"product": {
"name": "openSUSE Leap",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP6",
"product": {
"name": "SUSE Linux Enterprise Live Patching",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 12 SP5",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP7",
"product": {
"name": "SUSE Linux Enterprise Live Patching",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 12 SP5",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server High Availability Extension 16.0",
"product": {
"name": "SUSE Linux Enterprise High Availability Extension",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP5",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Micro Extras 6.1",
"product": {
"name": "SUSE Linux Micro Extras",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP5",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.6",
"product": {
"name": "openSUSE Leap",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.3",
"product": {
"name": "SUSE Linux Enterprise Micro",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP5",
"product": {
"name": "SUSE Linux Enterprise Real Time",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP applications 16.0",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP6",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP4",
"product": {
"name": "SUSE Linux Enterprise Real Time",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP7",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP4",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.5",
"product": {
"name": "SUSE Linux Enterprise Micro",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP4",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP6",
"product": {
"name": "SUSE Linux Enterprise Real Time",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Micro 6.1",
"product": {
"name": "SUSE Linux Micro",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Micro 6.0",
"product": {
"name": "SUSE Linux Micro",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP7",
"product": {
"name": "SUSE Linux Enterprise Server",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.4",
"product": {
"name": "SUSE Linux Enterprise Micro",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP4",
"product": {
"name": "SUSE Linux Enterprise Live Patching",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Micro Extras 6.0",
"product": {
"name": "SUSE Linux Micro Extras",
"vendor": {
"name": "SUSE",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2026-43198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43198"
},
{
"name": "CVE-2026-43366",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43366"
},
{
"name": "CVE-2026-46119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46119"
},
{
"name": "CVE-2026-43298",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43298"
},
{
"name": "CVE-2026-53272",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53272"
},
{
"name": "CVE-2026-53049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53049"
},
{
"name": "CVE-2026-52955",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52955"
},
{
"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-43468",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43468"
},
{
"name": "CVE-2026-45884",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45884"
},
{
"name": "CVE-2026-43374",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43374"
},
{
"name": "CVE-2026-43373",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43373"
},
{
"name": "CVE-2026-53090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53090"
},
{
"name": "CVE-2026-53287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53287"
},
{
"name": "CVE-2026-46124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46124"
},
{
"name": "CVE-2026-53274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53274"
},
{
"name": "CVE-2026-31758",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31758"
},
{
"name": "CVE-2026-46076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46076"
},
{
"name": "CVE-2026-53041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53041"
},
{
"name": "CVE-2026-43161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43161"
},
{
"name": "CVE-2026-43457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43457"
},
{
"name": "CVE-2026-45922",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45922"
},
{
"name": "CVE-2026-43119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43119"
},
{
"name": "CVE-2026-31685",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31685"
},
{
"name": "CVE-2026-43240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43240"
},
{
"name": "CVE-2026-52958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52958"
},
{
"name": "CVE-2026-46319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46319"
},
{
"name": "CVE-2026-53229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53229"
},
{
"name": "CVE-2026-43470",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43470"
},
{
"name": "CVE-2026-43492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43492"
},
{
"name": "CVE-2026-46065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46065"
},
{
"name": "CVE-2026-46227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46227"
},
{
"name": "CVE-2026-53040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53040"
},
{
"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-43294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43294"
},
{
"name": "CVE-2026-46253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46253"
},
{
"name": "CVE-2026-43339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43339"
},
{
"name": "CVE-2026-31664",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31664"
},
{
"name": "CVE-2023-20585",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-20585"
},
{
"name": "CVE-2026-46112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46112"
},
{
"name": "CVE-2026-31752",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31752"
},
{
"name": "CVE-2026-46063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46063"
},
{
"name": "CVE-2026-52924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52924"
},
{
"name": "CVE-2026-45901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45901"
},
{
"name": "CVE-2026-43167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43167"
},
{
"name": "CVE-2026-43248",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43248"
},
{
"name": "CVE-2026-43132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43132"
},
{
"name": "CVE-2026-43092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43092"
},
{
"name": "CVE-2026-31680",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31680"
},
{
"name": "CVE-2026-31586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31586"
},
{
"name": "CVE-2026-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53181"
},
{
"name": "CVE-2026-43465",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43465"
},
{
"name": "CVE-2026-45888",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45888"
},
{
"name": "CVE-2026-53286",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53286"
},
{
"name": "CVE-2026-31738",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31738"
},
{
"name": "CVE-2026-53081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53081"
},
{
"name": "CVE-2026-52993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52993"
},
{
"name": "CVE-2026-43284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43284"
},
{
"name": "CVE-2026-43010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43010"
},
{
"name": "CVE-2026-52956",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52956"
},
{
"name": "CVE-2026-52943",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52943"
},
{
"name": "CVE-2026-43025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43025"
},
{
"name": "CVE-2026-46173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46173"
},
{
"name": "CVE-2026-46214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46214"
},
{
"name": "CVE-2026-43053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43053"
},
{
"name": "CVE-2026-53103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53103"
},
{
"name": "CVE-2026-31502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31502"
},
{
"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-45870",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45870"
},
{
"name": "CVE-2026-43445",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43445"
},
{
"name": "CVE-2026-46320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46320"
},
{
"name": "CVE-2026-43028",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43028"
},
{
"name": "CVE-2026-46113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46113"
},
{
"name": "CVE-2026-43415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43415"
},
{
"name": "CVE-2026-46071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46071"
},
{
"name": "CVE-2026-45841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45841"
},
{
"name": "CVE-2026-43022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43022"
},
{
"name": "CVE-2026-31505",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31505"
},
{
"name": "CVE-2026-46331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46331"
},
{
"name": "CVE-2026-53015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53015"
},
{
"name": "CVE-2026-52961",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52961"
},
{
"name": "CVE-2026-43458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43458"
},
{
"name": "CVE-2026-52919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52919"
},
{
"name": "CVE-2026-43450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43450"
},
{
"name": "CVE-2026-43345",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43345"
},
{
"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-46091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46091"
},
{
"name": "CVE-2026-46024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46024"
},
{
"name": "CVE-2026-53266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53266"
},
{
"name": "CVE-2026-45861",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45861"
},
{
"name": "CVE-2026-46037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46037"
},
{
"name": "CVE-2026-46116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46116"
},
{
"name": "CVE-2026-43213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43213"
},
{
"name": "CVE-2026-43057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43057"
},
{
"name": "CVE-2026-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53176"
},
{
"name": "CVE-2026-31663",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31663"
},
{
"name": "CVE-2026-43074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43074"
},
{
"name": "CVE-2026-45912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45912"
},
{
"name": "CVE-2026-43383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43383"
},
{
"name": "CVE-2026-52975",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52975"
},
{
"name": "CVE-2026-46259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46259"
},
{
"name": "CVE-2026-31647",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31647"
},
{
"name": "CVE-2026-53050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53050"
},
{
"name": "CVE-2026-43080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43080"
},
{
"name": "CVE-2026-31693",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31693"
},
{
"name": "CVE-2026-46178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46178"
},
{
"name": "CVE-2026-45862",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45862"
},
{
"name": "CVE-2026-43036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43036"
},
{
"name": "CVE-2026-53021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53021"
},
{
"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-2025-39894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39894"
},
{
"name": "CVE-2026-46005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46005"
},
{
"name": "CVE-2026-45894",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45894"
},
{
"name": "CVE-2026-46069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46069"
},
{
"name": "CVE-2026-53178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53178"
},
{
"name": "CVE-2026-31670",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31670"
},
{
"name": "CVE-2026-23240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23240"
},
{
"name": "CVE-2026-31533",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31533"
},
{
"name": "CVE-2026-46059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46059"
},
{
"name": "CVE-2026-31469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31469"
},
{
"name": "CVE-2026-46120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46120"
},
{
"name": "CVE-2026-43336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43336"
},
{
"name": "CVE-2026-52954",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52954"
},
{
"name": "CVE-2026-53249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53249"
},
{
"name": "CVE-2026-53139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53139"
},
{
"name": "CVE-2026-43466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43466"
},
{
"name": "CVE-2026-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53217"
},
{
"name": "CVE-2026-53262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53262"
},
{
"name": "CVE-2026-31555",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31555"
},
{
"name": "CVE-2026-43253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43253"
},
{
"name": "CVE-2026-31580",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31580"
},
{
"name": "CVE-2026-43491",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43491"
},
{
"name": "CVE-2026-46242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46242"
},
{
"name": "CVE-2026-43403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43403"
},
{
"name": "CVE-2026-43452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43452"
},
{
"name": "CVE-2026-45999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45999"
},
{
"name": "CVE-2026-43019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43019"
},
{
"name": "CVE-2026-46243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46243"
},
{
"name": "CVE-2026-43260",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43260"
},
{
"name": "CVE-2026-53362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53362"
},
{
"name": "CVE-2026-43205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43205"
},
{
"name": "CVE-2026-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53168"
},
{
"name": "CVE-2026-53053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53053"
},
{
"name": "CVE-2026-53086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53086"
},
{
"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-45940",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45940"
},
{
"name": "CVE-2025-10263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10263"
},
{
"name": "CVE-2026-31450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31450"
},
{
"name": "CVE-2026-43024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43024"
},
{
"name": "CVE-2026-45985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45985"
},
{
"name": "CVE-2026-53167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53167"
},
{
"name": "CVE-2026-53060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53060"
},
{
"name": "CVE-2026-46289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46289"
},
{
"name": "CVE-2026-43407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43407"
},
{
"name": "CVE-2026-52908",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52908"
},
{
"name": "CVE-2026-45899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45899"
},
{
"name": "CVE-2026-53035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53035"
},
{
"name": "CVE-2026-45997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45997"
},
{
"name": "CVE-2026-43405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43405"
},
{
"name": "CVE-2025-40341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40341"
},
{
"name": "CVE-2026-43437",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43437"
},
{
"name": "CVE-2026-45920",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45920"
},
{
"name": "CVE-2026-46150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46150"
},
{
"name": "CVE-2026-45840",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45840"
},
{
"name": "CVE-2026-53245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53245"
},
{
"name": "CVE-2026-43035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43035"
},
{
"name": "CVE-2026-46172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46172"
},
{
"name": "CVE-2025-71089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71089"
},
{
"name": "CVE-2026-31429",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31429"
},
{
"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-53285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53285"
},
{
"name": "CVE-2026-31743",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31743"
},
{
"name": "CVE-2026-43304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43304"
},
{
"name": "CVE-2026-45961",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45961"
},
{
"name": "CVE-2026-43384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43384"
},
{
"name": "CVE-2026-43158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43158"
},
{
"name": "CVE-2026-43501",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43501"
},
{
"name": "CVE-2026-53133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53133"
},
{
"name": "CVE-2026-43093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43093"
},
{
"name": "CVE-2026-31479",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31479"
},
{
"name": "CVE-2026-46266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46266"
},
{
"name": "CVE-2026-43337",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43337"
},
{
"name": "CVE-2026-53263",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53263"
},
{
"name": "CVE-2026-46111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46111"
},
{
"name": "CVE-2026-43238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43238"
},
{
"name": "CVE-2026-46291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46291"
},
{
"name": "CVE-2026-46046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46046"
},
{
"name": "CVE-2026-43086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43086"
},
{
"name": "CVE-2026-31771",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31771"
},
{
"name": "CVE-2026-52980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52980"
},
{
"name": "CVE-2026-53194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53194"
},
{
"name": "CVE-2026-43034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43034"
},
{
"name": "CVE-2026-43124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43124"
},
{
"name": "CVE-2026-43094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43094"
},
{
"name": "CVE-2026-43204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43204"
},
{
"name": "CVE-2026-43015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43015"
},
{
"name": "CVE-2026-43120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43120"
},
{
"name": "CVE-2026-45970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45970"
},
{
"name": "CVE-2026-43469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43469"
},
{
"name": "CVE-2026-43085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43085"
},
{
"name": "CVE-2026-43199",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43199"
},
{
"name": "CVE-2026-31466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31466"
},
{
"name": "CVE-2026-53258",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53258"
},
{
"name": "CVE-2026-31414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31414"
},
{
"name": "CVE-2026-46244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46244"
},
{
"name": "CVE-2026-53039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53039"
},
{
"name": "CVE-2026-43191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43191"
},
{
"name": "CVE-2026-43190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43190"
},
{
"name": "CVE-2026-43226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43226"
},
{
"name": "CVE-2026-53357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53357"
},
{
"name": "CVE-2026-43456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43456"
},
{
"name": "CVE-2026-43406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43406"
},
{
"name": "CVE-2026-31570",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31570"
},
{
"name": "CVE-2026-53215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53215"
},
{
"name": "CVE-2026-53216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53216"
},
{
"name": "CVE-2026-45964",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45964"
},
{
"name": "CVE-2026-46314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46314"
},
{
"name": "CVE-2026-43187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43187"
},
{
"name": "CVE-2026-43081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43081"
},
{
"name": "CVE-2026-53359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53359"
},
{
"name": "CVE-2026-31495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31495"
},
{
"name": "CVE-2026-46160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46160"
},
{
"name": "CVE-2026-46079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46079"
},
{
"name": "CVE-2026-53256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53256"
},
{
"name": "CVE-2026-53306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53306"
},
{
"name": "CVE-2026-43303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43303"
},
{
"name": "CVE-2026-43386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43386"
},
{
"name": "CVE-2026-31492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31492"
},
{
"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-46162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46162"
},
{
"name": "CVE-2026-31596",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31596"
},
{
"name": "CVE-2026-43083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43083"
},
{
"name": "CVE-2026-23393",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23393"
},
{
"name": "CVE-2026-43502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43502"
},
{
"name": "CVE-2026-31674",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31674"
},
{
"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-52909",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52909"
},
{
"name": "CVE-2026-45858",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45858"
},
{
"name": "CVE-2026-23394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23394"
},
{
"name": "CVE-2026-45838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45838"
},
{
"name": "CVE-2026-45933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45933"
},
{
"name": "CVE-2026-45891",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45891"
},
{
"name": "CVE-2026-31560",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31560"
},
{
"name": "CVE-2026-52962",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52962"
},
{
"name": "CVE-2026-43101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43101"
},
{
"name": "CVE-2026-53075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53075"
},
{
"name": "CVE-2026-45837",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45837"
},
{
"name": "CVE-2026-45987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45987"
},
{
"name": "CVE-2026-43471",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43471"
},
{
"name": "CVE-2026-46093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46093"
},
{
"name": "CVE-2026-31503",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31503"
},
{
"name": "CVE-2026-43016",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43016"
},
{
"name": "CVE-2026-46050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46050"
},
{
"name": "CVE-2026-43175",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43175"
},
{
"name": "CVE-2026-31646",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31646"
},
{
"name": "CVE-2026-43320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43320"
},
{
"name": "CVE-2026-23451",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23451"
},
{
"name": "CVE-2026-53078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53078"
},
{
"name": "CVE-2026-53281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53281"
},
{
"name": "CVE-2026-43194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43194"
},
{
"name": "CVE-2026-43473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43473"
},
{
"name": "CVE-2026-43107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43107"
},
{
"name": "CVE-2026-23248",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23248"
},
{
"name": "CVE-2026-53366",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53366"
},
{
"name": "CVE-2026-52923",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52923"
},
{
"name": "CVE-2026-43171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43171"
},
{
"name": "CVE-2026-43351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43351"
},
{
"name": "CVE-2026-52933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52933"
},
{
"name": "CVE-2026-43128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43128"
},
{
"name": "CVE-2026-43090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43090"
},
{
"name": "CVE-2026-53122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53122"
},
{
"name": "CVE-2026-53196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53196"
},
{
"name": "CVE-2026-45983",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45983"
},
{
"name": "CVE-2026-53156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53156"
},
{
"name": "CVE-2026-43038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43038"
},
{
"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-46052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46052"
},
{
"name": "CVE-2026-43130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43130"
},
{
"name": "CVE-2026-31452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31452"
},
{
"name": "CVE-2026-46053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46053"
},
{
"name": "CVE-2026-31499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31499"
},
{
"name": "CVE-2026-46051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46051"
},
{
"name": "CVE-2026-43157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43157"
},
{
"name": "CVE-2026-46322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46322"
},
{
"name": "CVE-2026-53036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53036"
},
{
"name": "CVE-2026-43283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43283"
},
{
"name": "CVE-2026-46254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46254"
},
{
"name": "CVE-2026-46078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46078"
},
{
"name": "CVE-2026-31438",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31438"
},
{
"name": "CVE-2026-43494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43494"
},
{
"name": "CVE-2026-31673",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31673"
}
],
"initial_release_date": "2026-07-31T00:00:00",
"last_revision_date": "2026-07-31T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0956",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-07-31T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de SUSE. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es, une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es et un contournement de la politique de s\u00e9curit\u00e9.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de SUSE",
"vendor_advisories": [
{
"published_at": "2026-07-21",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22835-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622835-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3345-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263345-1"
},
{
"published_at": "2026-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22809-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622809-1"
},
{
"published_at": "2026-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22811-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622811-1"
},
{
"published_at": "2026-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22810-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622810-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3350-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263350-1"
},
{
"published_at": "2026-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22916-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622916-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3351-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263351-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3376-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263376-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3343-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263343-1"
},
{
"published_at": "2026-07-27",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3286-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263286-1"
},
{
"published_at": "2026-07-17",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22794-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622794-1"
},
{
"published_at": "2026-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22883-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622883-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3393-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263393-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3369-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263369-1"
},
{
"published_at": "2026-07-21",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22812-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622812-1"
},
{
"published_at": "2026-07-27",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3289-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263289-1"
},
{
"published_at": "2026-07-27",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3301-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263301-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3354-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263354-1"
},
{
"published_at": "2026-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22790-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622790-1"
},
{
"published_at": "2026-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22903-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622903-1"
},
{
"published_at": "2026-07-25",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE suse-su-20263246-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263246-1"
},
{
"published_at": "2026-07-27",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3264-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263264-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3321-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263321-1"
},
{
"published_at": "2026-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22791-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622791-1"
},
{
"published_at": "2026-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22911-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622911-1"
},
{
"published_at": "2026-07-27",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE suse-su-20263256-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263256-1"
},
{
"published_at": "2026-07-27",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3316-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263316-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3344-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263344-1"
},
{
"published_at": "2026-07-26",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3254-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263254-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3392-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263392-1"
},
{
"published_at": "2026-07-25",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE suse-su-20263248-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263248-1"
},
{
"published_at": "2026-07-25",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE suse-su-20263253-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263253-1"
},
{
"published_at": "2026-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22904-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622904-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3372-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263372-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3319-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263319-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3383-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263383-1"
},
{
"published_at": "2026-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22808-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622808-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:3388-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-20263388-1"
},
{
"published_at": "2026-07-17",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2026:22795-1",
"url": "https://www.suse.com/support/update/announcement/2026/suse-su-202622795-1"
}
]
}
CERTFR-2026-AVI-1094
Vulnerability from certfr_avis - Published: 2026-08-28 - Updated: 2026-08-28
De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| IBM | WebSphere | WebSphere Application Server Liberty versions 17.0.0.3 à 26.0.0.7 sans le correctif de sécurité PH71585 | ||
| IBM | QRadar | QRadar SIEM versions 7.5.x antérieures à 7.5.0 UP15 IF06 | ||
| IBM | Tivoli | Tivoli System Automation Application Manager version 4.1 avec WebSphere Application Server sans les derniers correctifs de sécurité | ||
| IBM | Sterling | Sterling Control Center version 6.3.1.0 antérieure à 6.3.1.0 iFix11 | ||
| IBM | Db2 | Db2 versions 11.5.x antérieures à 11.5.9 sans le dernier correctif de sécurité | ||
| IBM | Sterling | Sterling Connect:Direct File Agent versions 1.4.0.3x à 1.4.0.5x antérieures à 1.4.0.5_iFix016 | ||
| IBM | Db2 | Db2 versions 12.1.x antérieures à 12.1.4 sans le dernier correctif de sécurité | ||
| IBM | Spectrum | Spectrum Control versions antérieures à 5.5 | ||
| IBM | Sterling | Sterling Control Center version 6.4.2.0 antérieure à 6.4.2.0 iFix06 | ||
| IBM | QRadar | QRadar SIEM versions 7.6.x antérieures à 7.6.0.3 | ||
| IBM | QRadar | Security QRadar EDR versions 3.12.x antérieures à 3.12.26 | ||
| IBM | WebSphere | WebSphere Hybrid Edition version 5.1 sans les correctifs de sécurité APAR DT496328, DT496327 et DT497580 | ||
| IBM | Db2 | Db2 Genius Hub & Agentics versions 1.1.x antérieures à 1.1.4 | ||
| IBM | Tivoli | Tivoli Application Dependency Discovery Manager versions 7.3.0.0 à 7.3.0.12 avec WebSphere Application Server Liberty versions antérieures à 26.0.0.8 | ||
| IBM | WebSphere | WebSphere Extreme Scale versions 8.6.1.x antérieures à 8.6.1.6 avec le correctif de sécurité PH72588 | ||
| IBM | Sterling | Sterling Connect:Direct for Unix versions 6.3.0.x antérieures à 6.3.0.7.iFix026 | ||
| IBM | Sterling | Sterling Connect:Direct for Unix versions 6.4.0.x antérieures à 6.4.0.6.iFix014 | ||
| IBM | QRadar | QRadar Suite Software versions 1.10.12.0 à 1.11.10.0 antérieures à 1.11.12.0 | ||
| IBM | QRadar | QRadar AI Assistant versions antérieures à 2.2.0 |
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "WebSphere Application Server Liberty versions 17.0.0.3 \u00e0 26.0.0.7 sans le correctif de s\u00e9curit\u00e9 PH71585",
"product": {
"name": "WebSphere",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "QRadar SIEM versions 7.5.x ant\u00e9rieures \u00e0 7.5.0 UP15 IF06",
"product": {
"name": "QRadar",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Tivoli System Automation Application Manager version 4.1 avec WebSphere Application Server sans les derniers correctifs de s\u00e9curit\u00e9",
"product": {
"name": "Tivoli",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Control Center version 6.3.1.0 ant\u00e9rieure \u00e0 6.3.1.0 iFix11",
"product": {
"name": "Sterling",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 versions 11.5.x ant\u00e9rieures \u00e0 11.5.9 sans le dernier correctif de s\u00e9curit\u00e9",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Connect:Direct File Agent versions 1.4.0.3x \u00e0 1.4.0.5x ant\u00e9rieures \u00e0 1.4.0.5_iFix016",
"product": {
"name": "Sterling",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 versions 12.1.x ant\u00e9rieures \u00e0 12.1.4 sans le dernier correctif de s\u00e9curit\u00e9",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Spectrum Control versions ant\u00e9rieures \u00e0 5.5",
"product": {
"name": "Spectrum",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Control Center version 6.4.2.0 ant\u00e9rieure \u00e0 6.4.2.0 iFix06",
"product": {
"name": "Sterling",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "QRadar SIEM versions 7.6.x ant\u00e9rieures \u00e0 7.6.0.3",
"product": {
"name": "QRadar",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Security QRadar EDR versions 3.12.x ant\u00e9rieures \u00e0 3.12.26",
"product": {
"name": "QRadar",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "WebSphere Hybrid Edition version 5.1 sans les correctifs de s\u00e9curit\u00e9 APAR DT496328, DT496327 et DT497580",
"product": {
"name": "WebSphere",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 Genius Hub \u0026 Agentics versions 1.1.x ant\u00e9rieures \u00e0 1.1.4",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Tivoli Application Dependency Discovery Manager versions 7.3.0.0 \u00e0 7.3.0.12 avec WebSphere Application Server Liberty versions ant\u00e9rieures \u00e0 26.0.0.8",
"product": {
"name": "Tivoli",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "WebSphere Extreme Scale versions 8.6.1.x ant\u00e9rieures \u00e0 8.6.1.6 avec le correctif de s\u00e9curit\u00e9 PH72588",
"product": {
"name": "WebSphere",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Connect:Direct for Unix versions 6.3.0.x ant\u00e9rieures \u00e0 6.3.0.7.iFix026",
"product": {
"name": "Sterling",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Connect:Direct for Unix versions 6.4.0.x ant\u00e9rieures \u00e0 6.4.0.6.iFix014",
"product": {
"name": "Sterling",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "QRadar Suite Software versions 1.10.12.0 \u00e0 1.11.10.0 ant\u00e9rieures \u00e0 1.11.12.0",
"product": {
"name": "QRadar",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "QRadar AI Assistant versions ant\u00e9rieures \u00e0 2.2.0",
"product": {
"name": "QRadar",
"vendor": {
"name": "IBM",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2026-41411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41411"
},
{
"name": "CVE-2026-14380",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14380"
},
{
"name": "CVE-2026-26007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26007"
},
{
"name": "CVE-2026-43198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43198"
},
{
"name": "CVE-2026-54293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54293"
},
{
"name": "CVE-2026-49978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49978"
},
{
"name": "CVE-2026-9697",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9697"
},
{
"name": "CVE-2026-53540",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53540"
},
{
"name": "CVE-2026-54283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54283"
},
{
"name": "CVE-2026-54369",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54369"
},
{
"name": "CVE-2026-40466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40466"
},
{
"name": "CVE-2026-59724",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59724"
},
{
"name": "CVE-2026-45505",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45505"
},
{
"name": "CVE-2026-4878",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-4878"
},
{
"name": "CVE-2026-49476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49476"
},
{
"name": "CVE-2026-42588",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42588"
},
{
"name": "CVE-2026-27205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27205"
},
{
"name": "CVE-2026-59205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59205"
},
{
"name": "CVE-2026-33845",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33845"
},
{
"name": "CVE-2026-41254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41254"
},
{
"name": "CVE-2026-42253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42253"
},
{
"name": "CVE-2026-44405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44405"
},
{
"name": "CVE-2026-50645",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50645"
},
{
"name": "CVE-2026-44289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44289"
},
{
"name": "CVE-2026-42041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42041"
},
{
"name": "CVE-2026-9679",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9679"
},
{
"name": "CVE-2026-39892",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-39892"
},
{
"name": "CVE-2026-10050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10050"
},
{
"name": "CVE-2024-24762",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24762"
},
{
"name": "CVE-2026-42402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42402"
},
{
"name": "CVE-2026-42561",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42561"
},
{
"name": "CVE-2025-14505",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14505"
},
{
"name": "CVE-2026-16184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16184"
},
{
"name": "CVE-2026-15328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15328"
},
{
"name": "CVE-2026-32286",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32286"
},
{
"name": "CVE-2026-46227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46227"
},
{
"name": "CVE-2026-57455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-57455"
},
{
"name": "CVE-2026-54514",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54514"
},
{
"name": "CVE-2026-44293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44293"
},
{
"name": "CVE-2026-44290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44290"
},
{
"name": "CVE-2021-23336",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-23336"
},
{
"name": "CVE-2026-55276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55276"
},
{
"name": "CVE-2026-48710",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48710"
},
{
"name": "CVE-2026-16243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16243"
},
{
"name": "CVE-2026-9171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9171"
},
{
"name": "CVE-2025-47279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47279"
},
{
"name": "CVE-2025-40026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40026"
},
{
"name": "CVE-2026-47010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47010"
},
{
"name": "CVE-2026-69249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69249"
},
{
"name": "CVE-2026-54058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54058"
},
{
"name": "CVE-2026-55653",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55653"
},
{
"name": "CVE-2026-41239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41239"
},
{
"name": "CVE-2026-46117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46117"
},
{
"name": "CVE-2026-59084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59084"
},
{
"name": "CVE-2026-45740",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45740"
},
{
"name": "CVE-2025-14920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14920"
},
{
"name": "CVE-2026-52993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52993"
},
{
"name": "CVE-2026-59725",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59725"
},
{
"name": "CVE-2026-14739",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14739"
},
{
"name": "CVE-2026-39824",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-39824"
},
{
"name": "CVE-2026-46605",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46605"
},
{
"name": "CVE-2026-54275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54275"
},
{
"name": "CVE-2026-22013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22013"
},
{
"name": "CVE-2026-47057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47057"
},
{
"name": "CVE-2026-10846",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10846"
},
{
"name": "CVE-2026-22018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22018"
},
{
"name": "CVE-2026-12505",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12505"
},
{
"name": "CVE-2026-35469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-35469"
},
{
"name": "CVE-2026-9698",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9698"
},
{
"name": "CVE-2026-42015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42015"
},
{
"name": "CVE-2026-14528",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14528"
},
{
"name": "CVE-2026-54278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54278"
},
{
"name": "CVE-2026-53538",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53538"
},
{
"name": "CVE-2026-18499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18499"
},
{
"name": "CVE-2026-46113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46113"
},
{
"name": "CVE-2026-54515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54515"
},
{
"name": "CVE-2026-53550",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53550"
},
{
"name": "CVE-2026-43279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43279"
},
{
"name": "CVE-2026-53071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53071"
},
{
"name": "CVE-2026-49157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49157"
},
{
"name": "CVE-2026-16221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16221"
},
{
"name": "CVE-2026-55798",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55798"
},
{
"name": "CVE-2026-6790",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6790"
},
{
"name": "CVE-2026-7246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-7246"
},
{
"name": "CVE-2026-15308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15308"
},
{
"name": "CVE-2026-66143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66143"
},
{
"name": "CVE-2026-46331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46331"
},
{
"name": "CVE-2026-66144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66144"
},
{
"name": "CVE-2026-44494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44494"
},
{
"name": "CVE-2026-55153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55153"
},
{
"name": "CVE-2026-46209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46209"
},
{
"name": "CVE-2026-11541",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11541"
},
{
"name": "CVE-2026-34282",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34282"
},
{
"name": "CVE-2026-44618",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44618"
},
{
"name": "CVE-2026-42036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42036"
},
{
"name": "CVE-2026-33236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33236"
},
{
"name": "CVE-2026-54475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54475"
},
{
"name": "CVE-2026-31692",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31692"
},
{
"name": "CVE-2026-44240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44240"
},
{
"name": "CVE-2026-55443",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55443"
},
{
"name": "CVE-2026-65900",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65900"
},
{
"name": "CVE-2026-33558",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33558"
},
{
"name": "CVE-2026-53916",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53916"
},
{
"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-33846",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33846"
},
{
"name": "CVE-2026-42403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42403"
},
{
"name": "CVE-2026-34043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34043"
},
{
"name": "CVE-2026-59880",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59880"
},
{
"name": "CVE-2026-15057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15057"
},
{
"name": "CVE-2026-59890",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59890"
},
{
"name": "CVE-2026-53266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53266"
},
{
"name": "CVE-2025-64718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64718"
},
{
"name": "CVE-2026-46116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46116"
},
{
"name": "CVE-2026-14742",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14742"
},
{
"name": "CVE-2025-62718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62718"
},
{
"name": "CVE-2026-44990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44990"
},
{
"name": "CVE-2026-47265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47265"
},
{
"name": "CVE-2026-49458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49458"
},
{
"name": "CVE-2026-54282",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54282"
},
{
"name": "CVE-2026-46259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46259"
},
{
"name": "CVE-2026-0540",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0540"
},
{
"name": "CVE-2026-45149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45149"
},
{
"name": "CVE-2026-45249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45249"
},
{
"name": "CVE-2026-23865",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23865"
},
{
"name": "CVE-2026-48988",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48988"
},
{
"name": "CVE-2026-43499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43499"
},
{
"name": "CVE-2026-11525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11525"
},
{
"name": "CVE-2026-15325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15325"
},
{
"name": "CVE-2026-59199",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59199"
},
{
"name": "CVE-2026-69247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69247"
},
{
"name": "CVE-2026-33671",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33671"
},
{
"name": "CVE-2026-34515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34515"
},
{
"name": "CVE-2026-14976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14976"
},
{
"name": "CVE-2026-48864",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48864"
},
{
"name": "CVE-2026-34519",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34519"
},
{
"name": "CVE-2026-42033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42033"
},
{
"name": "CVE-2026-42035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42035"
},
{
"name": "CVE-2026-54277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54277"
},
{
"name": "CVE-2026-69248",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69248"
},
{
"name": "CVE-2026-18446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18446"
},
{
"name": "CVE-2026-5450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5450"
},
{
"name": "CVE-2026-14512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14512"
},
{
"name": "CVE-2026-5260",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5260"
},
{
"name": "CVE-2026-42009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42009"
},
{
"name": "CVE-2026-54059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54059"
},
{
"name": "CVE-2026-10842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10842"
},
{
"name": "CVE-2026-46189",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46189"
},
{
"name": "CVE-2026-33750",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33750"
},
{
"name": "CVE-2026-5038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5038"
},
{
"name": "CVE-2026-40186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40186"
},
{
"name": "CVE-2026-2359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2359"
},
{
"name": "CVE-2026-42043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42043"
},
{
"name": "CVE-2026-44288",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44288"
},
{
"name": "CVE-2026-41603",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41603"
},
{
"name": "CVE-2026-8646",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8646"
},
{
"name": "CVE-2026-45822",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45822"
},
{
"name": "CVE-2026-6918",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6918"
},
{
"name": "CVE-2026-55380",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55380"
},
{
"name": "CVE-2026-54280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54280"
},
{
"name": "CVE-2026-46625",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46625"
},
{
"name": "CVE-2026-25749",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25749"
},
{
"name": "CVE-2026-44489",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44489"
},
{
"name": "CVE-2026-12413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12413"
},
{
"name": "CVE-2026-59869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59869"
},
{
"name": "CVE-2026-3833",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3833"
},
{
"name": "CVE-2025-13151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13151"
},
{
"name": "CVE-2026-9320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9320"
},
{
"name": "CVE-2026-49459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49459"
},
{
"name": "CVE-2026-66053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66053"
},
{
"name": "CVE-2026-41044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41044"
},
{
"name": "CVE-2026-41043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41043"
},
{
"name": "CVE-2026-5079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5079"
},
{
"name": "CVE-2026-34518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34518"
},
{
"name": "CVE-2026-50734",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50734"
},
{
"name": "CVE-2026-44930",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44930"
},
{
"name": "CVE-2026-14974",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14974"
},
{
"name": "CVE-2026-41240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41240"
},
{
"name": "CVE-2026-42010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42010"
},
{
"name": "CVE-2026-5435",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5435"
},
{
"name": "CVE-2026-4427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-4427"
},
{
"name": "CVE-2026-59887",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59887"
},
{
"name": "CVE-2026-59203",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59203"
},
{
"name": "CVE-2025-10263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10263"
},
{
"name": "CVE-2026-42040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42040"
},
{
"name": "CVE-2026-47027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47027"
},
{
"name": "CVE-2026-23216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23216"
},
{
"name": "CVE-2026-47058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47058"
},
{
"name": "CVE-2026-42013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42013"
},
{
"name": "CVE-2026-62389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-62389"
},
{
"name": "CVE-2026-12151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12151"
},
{
"name": "CVE-2026-5928",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5928"
},
{
"name": "CVE-2026-16441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16441"
},
{
"name": "CVE-2026-27903",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27903"
},
{
"name": "CVE-2026-14981",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14981"
},
{
"name": "CVE-2026-6734",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6734"
},
{
"name": "CVE-2026-12243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12243"
},
{
"name": "CVE-2025-6170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6170"
},
{
"name": "CVE-2026-46150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46150"
},
{
"name": "CVE-2026-46090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46090"
},
{
"name": "CVE-2026-14529",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14529"
},
{
"name": "CVE-2026-34525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34525"
},
{
"name": "CVE-2025-71089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71089"
},
{
"name": "CVE-2026-54274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54274"
},
{
"name": "CVE-2026-54512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54512"
},
{
"name": "CVE-2026-59197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59197"
},
{
"name": "CVE-2026-57819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-57819"
},
{
"name": "CVE-2026-53059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53059"
},
{
"name": "CVE-2026-65899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65899"
},
{
"name": "CVE-2026-4539",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-4539"
},
{
"name": "CVE-2026-34197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34197"
},
{
"name": "CVE-2026-55956",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55956"
},
{
"name": "CVE-2026-54060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54060"
},
{
"name": "CVE-2026-41140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41140"
},
{
"name": "CVE-2025-48913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48913"
},
{
"name": "CVE-2026-59858",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59858"
},
{
"name": "CVE-2026-42404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42404"
},
{
"name": "CVE-2026-45984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45984"
},
{
"name": "CVE-2026-53537",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53537"
},
{
"name": "CVE-2026-40046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40046"
},
{
"name": "CVE-2026-16192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16192"
},
{
"name": "CVE-2026-50722",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50722"
},
{
"name": "CVE-2026-3304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3304"
},
{
"name": "CVE-2026-46145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46145"
},
{
"name": "CVE-2026-54273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54273"
},
{
"name": "CVE-2026-40895",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40895"
},
{
"name": "CVE-2026-42198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42198"
},
{
"name": "CVE-2026-47063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47063"
},
{
"name": "CVE-2026-14515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14515"
},
{
"name": "CVE-2026-22016",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22016"
},
{
"name": "CVE-2026-22021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22021"
},
{
"name": "CVE-2026-59083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59083"
},
{
"name": "CVE-2026-25243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25243"
},
{
"name": "CVE-2026-46135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46135"
},
{
"name": "CVE-2026-22007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22007"
},
{
"name": "CVE-2026-58016",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58016"
},
{
"name": "CVE-2026-43056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43056"
},
{
"name": "CVE-2026-59888",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59888"
},
{
"name": "CVE-2026-13149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13149"
},
{
"name": "CVE-2026-47021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47021"
},
{
"name": "CVE-2025-54410",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54410"
},
{
"name": "CVE-2026-46054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46054"
},
{
"name": "CVE-2025-69873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69873"
},
{
"name": "CVE-2026-49434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49434"
},
{
"name": "CVE-2026-42011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42011"
},
{
"name": "CVE-2026-34268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34268"
},
{
"name": "CVE-2026-16440",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16440"
},
{
"name": "CVE-2026-64958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64958"
},
{
"name": "CVE-2026-50721",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50721"
},
{
"name": "CVE-2025-71066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71066"
},
{
"name": "CVE-2026-44291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44291"
},
{
"name": "CVE-2026-15043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15043"
},
{
"name": "CVE-2026-66373",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66373"
},
{
"name": "CVE-2026-3520",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3520"
},
{
"name": "CVE-2026-55693",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55693"
},
{
"name": "CVE-2026-57456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-57456"
},
{
"name": "CVE-2026-29786",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-29786"
},
{
"name": "CVE-2026-44487",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44487"
},
{
"name": "CVE-2026-2482",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2482"
},
{
"name": "CVE-2026-11897",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11897"
},
{
"name": "CVE-2026-42038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42038"
},
{
"name": "CVE-2026-49844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49844"
},
{
"name": "CVE-2026-31419",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31419"
},
{
"name": "CVE-2026-41680",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41680"
},
{
"name": "CVE-2026-44292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44292"
},
{
"name": "CVE-2026-54370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54370"
},
{
"name": "CVE-2026-42039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42039"
},
{
"name": "CVE-2026-49432",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49432"
},
{
"name": "CVE-2026-59879",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59879"
},
{
"name": "CVE-2026-46968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46968"
},
{
"name": "CVE-2025-15599",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15599"
},
{
"name": "CVE-2026-55379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55379"
},
{
"name": "CVE-2026-31488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31488"
},
{
"name": "CVE-2026-9358",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9358"
},
{
"name": "CVE-2026-44417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44417"
},
{
"name": "CVE-2026-14446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14446"
},
{
"name": "CVE-2026-54279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54279"
},
{
"name": "CVE-2026-33672",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33672"
},
{
"name": "CVE-2026-6238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6238"
},
{
"name": "CVE-2026-8723",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8723"
},
{
"name": "CVE-2026-75838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75838"
},
{
"name": "CVE-2026-59200",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59200"
},
{
"name": "CVE-2025-58181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58181"
},
{
"name": "CVE-2025-47914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47914"
},
{
"name": "CVE-2026-59877",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59877"
},
{
"name": "CVE-2026-9678",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9678"
},
{
"name": "CVE-2026-39304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-39304"
},
{
"name": "CVE-2026-48713",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48713"
},
{
"name": "CVE-2026-49270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49270"
},
{
"name": "CVE-2026-34516",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34516"
},
{
"name": "CVE-2026-46086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46086"
},
{
"name": "CVE-2026-15064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15064"
},
{
"name": "CVE-2026-42044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42044"
},
{
"name": "CVE-2026-14476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14476"
},
{
"name": "CVE-2026-53359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53359"
},
{
"name": "CVE-2026-16439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16439"
},
{
"name": "CVE-2018-16487",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-16487"
},
{
"name": "CVE-2026-44728",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44728"
},
{
"name": "CVE-2026-55955",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55955"
},
{
"name": "CVE-2026-34517",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34517"
},
{
"name": "CVE-2026-49477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49477"
},
{
"name": "CVE-2026-42034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42034"
},
{
"name": "CVE-2026-9322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9322"
},
{
"name": "CVE-2025-5889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5889"
},
{
"name": "CVE-2026-31411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31411"
},
{
"name": "CVE-2026-54513",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54513"
},
{
"name": "CVE-2026-34591",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34591"
},
{
"name": "CVE-2026-48779",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48779"
},
{
"name": "CVE-2025-14914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14914"
},
{
"name": "CVE-2026-9563",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9563"
},
{
"name": "CVE-2026-13676",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13676"
},
{
"name": "CVE-2026-54276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54276"
},
{
"name": "CVE-2026-53434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53434"
},
{
"name": "CVE-2026-40347",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40347"
},
{
"name": "CVE-2026-43112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43112"
},
{
"name": "CVE-2025-66168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66168"
},
{
"name": "CVE-2026-66142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66142"
},
{
"name": "CVE-2026-10051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10051"
},
{
"name": "CVE-2026-6322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6322"
},
{
"name": "CVE-2026-34513",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34513"
},
{
"name": "CVE-2026-43869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43869"
},
{
"name": "CVE-2026-8400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8400"
},
{
"name": "CVE-2026-14980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14980"
},
{
"name": "CVE-2026-5078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5078"
},
{
"name": "CVE-2026-12143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12143"
},
{
"name": "CVE-2026-55655",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55655"
},
{
"name": "CVE-2026-34514",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34514"
},
{
"name": "CVE-2026-44431",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44431"
},
{
"name": "CVE-2026-27601",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27601"
},
{
"name": "CVE-2026-26996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26996"
},
{
"name": "CVE-2026-44486",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44486"
},
{
"name": "CVE-2026-33227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33227"
},
{
"name": "CVE-2026-48775",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48775"
},
{
"name": "CVE-2026-44496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44496"
},
{
"name": "CVE-2026-60081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-60081"
},
{
"name": "CVE-2026-10879",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10879"
},
{
"name": "CVE-2026-64530",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64530"
},
{
"name": "CVE-2026-44492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44492"
},
{
"name": "CVE-2026-45736",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45736"
},
{
"name": "CVE-2026-54225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54225"
},
{
"name": "CVE-2026-34520",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34520"
},
{
"name": "CVE-2026-41238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41238"
},
{
"name": "CVE-2026-42037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42037"
},
{
"name": "CVE-2026-53404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53404"
},
{
"name": "CVE-2026-33416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33416"
},
{
"name": "CVE-2026-42042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42042"
},
{
"name": "CVE-2026-9071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9071"
},
{
"name": "CVE-2026-34993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34993"
},
{
"name": "CVE-2026-59198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59198"
},
{
"name": "CVE-2026-11806",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11806"
},
{
"name": "CVE-2026-44294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44294"
},
{
"name": "CVE-2026-6321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6321"
},
{
"name": "CVE-2026-33231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33231"
},
{
"name": "CVE-2026-48801",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48801"
},
{
"name": "CVE-2026-52923",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52923"
},
{
"name": "CVE-2026-42012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42012"
},
{
"name": "CVE-2026-44490",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44490"
},
{
"name": "CVE-2026-46917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46917"
},
{
"name": "CVE-2026-43116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43116"
},
{
"name": "CVE-2026-60147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-60147"
},
{
"name": "CVE-2026-22815",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22815"
},
{
"name": "CVE-2026-15280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15280"
},
{
"name": "CVE-2026-22008",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22008"
},
{
"name": "CVE-2026-31802",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31802"
},
{
"name": "CVE-2026-56852",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56852"
},
{
"name": "CVE-2026-6733",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6733"
},
{
"name": "CVE-2026-13311",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13311"
},
{
"name": "CVE-2026-44488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44488"
},
{
"name": "CVE-2026-33230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33230"
},
{
"name": "CVE-2026-10535",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10535"
},
{
"name": "CVE-2026-34481",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34481"
},
{
"name": "CVE-2025-47273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47273"
},
{
"name": "CVE-2026-59204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59204"
},
{
"name": "CVE-2026-27904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27904"
},
{
"name": "CVE-2026-14474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14474"
},
{
"name": "CVE-2026-47059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47059"
},
{
"name": "CVE-2026-53539",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53539"
},
{
"name": "CVE-2026-2739",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2739"
},
{
"name": "CVE-2026-65898",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65898"
},
{
"name": "CVE-2026-53917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53917"
},
{
"name": "CVE-2026-15392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15392"
},
{
"name": "CVE-2026-8177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8177"
}
],
"initial_release_date": "2026-08-28T00:00:00",
"last_revision_date": "2026-08-28T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1094",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-08-28T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Injection de code indirecte \u00e0 distance (XSS)"
},
{
"description": "Injection de requ\u00eates ill\u00e9gitimes par rebond (CSRF)"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Falsification de requ\u00eates c\u00f4t\u00e9 serveur (SSRF)"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits IBM. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits IBM",
"vendor_advisories": [
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285382",
"url": "https://www.ibm.com/support/pages/node/7285382"
},
{
"published_at": "2026-08-24",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7284666",
"url": "https://www.ibm.com/support/pages/node/7284666"
},
{
"published_at": "2026-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285542",
"url": "https://www.ibm.com/support/pages/node/7285542"
},
{
"published_at": "2026-08-26",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285272",
"url": "https://www.ibm.com/support/pages/node/7285272"
},
{
"published_at": "2026-08-26",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285232",
"url": "https://www.ibm.com/support/pages/node/7285232"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285472",
"url": "https://www.ibm.com/support/pages/node/7285472"
},
{
"published_at": "2026-08-26",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285291",
"url": "https://www.ibm.com/support/pages/node/7285291"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285470",
"url": "https://www.ibm.com/support/pages/node/7285470"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285469",
"url": "https://www.ibm.com/support/pages/node/7285469"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7284528",
"url": "https://www.ibm.com/support/pages/node/7284528"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285416",
"url": "https://www.ibm.com/support/pages/node/7285416"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285376",
"url": "https://www.ibm.com/support/pages/node/7285376"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285380",
"url": "https://www.ibm.com/support/pages/node/7285380"
},
{
"published_at": "2026-08-26",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285275",
"url": "https://www.ibm.com/support/pages/node/7285275"
},
{
"published_at": "2026-08-26",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285292",
"url": "https://www.ibm.com/support/pages/node/7285292"
},
{
"published_at": "2026-08-26",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285234",
"url": "https://www.ibm.com/support/pages/node/7285234"
},
{
"published_at": "2026-08-26",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285141",
"url": "https://www.ibm.com/support/pages/node/7285141"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7279466",
"url": "https://www.ibm.com/support/pages/node/7279466"
},
{
"published_at": "2026-08-24",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7284718",
"url": "https://www.ibm.com/support/pages/node/7284718"
},
{
"published_at": "2026-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285509",
"url": "https://www.ibm.com/support/pages/node/7285509"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285340",
"url": "https://www.ibm.com/support/pages/node/7285340"
},
{
"published_at": "2026-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285513",
"url": "https://www.ibm.com/support/pages/node/7285513"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285420",
"url": "https://www.ibm.com/support/pages/node/7285420"
},
{
"published_at": "2026-08-24",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7284710",
"url": "https://www.ibm.com/support/pages/node/7284710"
},
{
"published_at": "2026-08-26",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285274",
"url": "https://www.ibm.com/support/pages/node/7285274"
},
{
"published_at": "2026-08-24",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7284653",
"url": "https://www.ibm.com/support/pages/node/7284653"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285342",
"url": "https://www.ibm.com/support/pages/node/7285342"
},
{
"published_at": "2026-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7285539",
"url": "https://www.ibm.com/support/pages/node/7285539"
},
{
"published_at": "2026-08-24",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7284670",
"url": "https://www.ibm.com/support/pages/node/7284670"
},
{
"published_at": "2026-08-24",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7284806",
"url": "https://www.ibm.com/support/pages/node/7284806"
}
]
}
FKIE_CVE-2025-71089
Vulnerability from fkie_nvd - Published: 2026-01-13 16:16 - Updated: 2026-06-17 10:037.8 (High) - CVSS:3.1/
| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/240cd7f2812cc25496b12063d11c823618f364e9 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/72f98ef9a4be30d2a60136dd6faee376f780d06c | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/7cad37e358970af1bb49030ff01f06a69fa7d985 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/b34289505180a83607fcfdce14b5a290d0528476 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/c2c3f1a3fd74ef16cf115f0c558616a13a8471b4 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/c341dee80b5df49a936182341b36395c831c2661 | Patch |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/iommu/iommu-sva.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b34289505180a83607fcfdce14b5a290d0528476",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "7cad37e358970af1bb49030ff01f06a69fa7d985",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "240cd7f2812cc25496b12063d11c823618f364e9",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "c2c3f1a3fd74ef16cf115f0c558616a13a8471b4",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "c341dee80b5df49a936182341b36395c831c2661",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
},
{
"lessThan": "72f98ef9a4be30d2a60136dd6faee376f780d06c",
"status": "affected",
"version": "26b25a2b98e45aeb40eedcedc586ad5034cbd984",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/iommu/iommu-sva.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.200",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.163",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E5B74AED-8F4D-46D6-9567-2309ADEA5E74",
"versionEndExcluding": "5.15.200",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E9C856E1-4308-4C0B-A973-7DD375DF66C4",
"versionEndExcluding": "6.1.163",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "43C3A206-5EEE-417B-AA0F-EF8972E7A9F0",
"versionEndExcluding": "6.6.120",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "32BF4A52-377C-44ED-B5E6-7EA5D896E98B",
"versionEndExcluding": "6.12.64",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "DC988EA0-0E32-457A-BF95-89BEB31A227B",
"versionEndExcluding": "6.18.4",
"versionStartIncluding": "6.13",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu: disable SVA when CONFIG_X86 is set\n\nPatch series \"Fix stale IOTLB entries for kernel address space\", v7.\n\nThis proposes a fix for a security vulnerability related to IOMMU Shared\nVirtual Addressing (SVA). In an SVA context, an IOMMU can cache kernel\npage table entries. When a kernel page table page is freed and\nreallocated for another purpose, the IOMMU might still hold stale,\nincorrect entries. This can be exploited to cause a use-after-free or\nwrite-after-free condition, potentially leading to privilege escalation or\ndata corruption.\n\nThis solution introduces a deferred freeing mechanism for kernel page\ntable pages, which provides a safe window to notify the IOMMU to\ninvalidate its caches before the page is reused.\n\n\nThis patch (of 8):\n\nIn the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware\nshares and walks the CPU\u0027s page tables. The x86 architecture maps the\nkernel\u0027s virtual address space into the upper portion of every process\u0027s\npage table. Consequently, in an SVA context, the IOMMU hardware can walk\nand cache kernel page table entries.\n\nThe Linux kernel currently lacks a notification mechanism for kernel page\ntable changes, specifically when page table pages are freed and reused. \nThe IOMMU driver is only notified of changes to user virtual address\nmappings. This can cause the IOMMU\u0027s internal caches to retain stale\nentries for kernel VA.\n\nUse-After-Free (UAF) and Write-After-Free (WAF) conditions arise when\nkernel page table pages are freed and later reallocated. The IOMMU could\nmisinterpret the new data as valid page table entries. The IOMMU might\nthen walk into attacker-controlled memory, leading to arbitrary physical\nmemory DMA access or privilege escalation. This is also a\nWrite-After-Free issue, as the IOMMU will potentially continue to write\nAccessed and Dirty bits to the freed memory while attempting to walk the\nstale page tables.\n\nCurrently, SVA contexts are unprivileged and cannot access kernel\nmappings. However, the IOMMU will still walk kernel-only page tables all\nthe way down to the leaf entries, where it realizes the mapping is for the\nkernel and errors out. This means the IOMMU still caches these\nintermediate page table entries, making the described vulnerability a real\nconcern.\n\nDisable SVA on x86 architecture until the IOMMU can receive notification\nto flush the paging cache before freeing the CPU kernel page table pages."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\niommu: deshabilitar SVA cuando CONFIG_X86 est\u00e1 configurado\n\nSerie de parches \u0027Correcci\u00f3n de entradas IOTLB obsoletas para el espacio de direcciones del kernel\u0027, v7.\n\nEsto propone una correcci\u00f3n para una vulnerabilidad de seguridad relacionada con el Direccionamiento Virtual Compartido (SVA) de IOMMU. En un contexto SVA, un IOMMU puede almacenar en cach\u00e9 entradas de la tabla de p\u00e1ginas del kernel. Cuando una p\u00e1gina de la tabla de p\u00e1ginas del kernel es liberada y reasignada para otro prop\u00f3sito, el IOMMU a\u00fan podr\u00eda contener entradas obsoletas e incorrectas. Esto puede ser explotado para causar una condici\u00f3n de uso despu\u00e9s de liberaci\u00f3n o de escritura despu\u00e9s de liberaci\u00f3n, lo que podr\u00eda llevar a una escalada de privilegios o a la corrupci\u00f3n de datos.\n\nEsta soluci\u00f3n introduce un mecanismo de liberaci\u00f3n diferida para las p\u00e1ginas de la tabla de p\u00e1ginas del kernel, que proporciona una ventana segura para notificar al IOMMU que invalide sus cach\u00e9s antes de que la p\u00e1gina sea reutilizada.\n\nEste parche (de 8):\n\nEn el contexto de Direccionamiento Virtual Compartido (SVA) de IOMMU, el hardware IOMMU comparte y recorre las tablas de p\u00e1ginas de la CPU. La arquitectura x86 mapea el espacio de direcciones virtual del kernel en la porci\u00f3n superior de la tabla de p\u00e1ginas de cada proceso. En consecuencia, en un contexto SVA, el hardware IOMMU puede recorrer y almacenar en cach\u00e9 entradas de la tabla de p\u00e1ginas del kernel.\n\nEl kernel de Linux actualmente carece de un mecanismo de notificaci\u00f3n para los cambios en la tabla de p\u00e1ginas del kernel, espec\u00edficamente cuando las p\u00e1ginas de la tabla de p\u00e1ginas son liberadas y reutilizadas. El controlador IOMMU solo es notificado de los cambios en las asignaciones de direcciones virtuales de usuario. Esto puede hacer que las cach\u00e9s internas del IOMMU retengan entradas obsoletas para VA del kernel.\n\nLas condiciones de Uso Despu\u00e9s de Liberaci\u00f3n (UAF) y Escritura Despu\u00e9s de Liberaci\u00f3n (WAF) surgen cuando las p\u00e1ginas de la tabla de p\u00e1ginas del kernel son liberadas y posteriormente reasignadas. El IOMMU podr\u00eda malinterpretar los nuevos datos como entradas v\u00e1lidas de la tabla de p\u00e1ginas. El IOMMU podr\u00eda entonces recorrer memoria controlada por el atacante, lo que llevar\u00eda a un acceso DMA arbitrario a la memoria f\u00edsica o a una escalada de privilegios. Esto tambi\u00e9n es un problema de Escritura Despu\u00e9s de Liberaci\u00f3n, ya que el IOMMU potencialmente continuar\u00e1 escribiendo bits de Acceso y Sucio en la memoria liberada mientras intenta recorrer las tablas de p\u00e1ginas obsoletas.\n\nActualmente, los contextos SVA no tienen privilegios y no pueden acceder a las asignaciones del kernel. Sin embargo, el IOMMU seguir\u00e1 recorriendo tablas de p\u00e1ginas solo del kernel hasta las entradas hoja, donde se da cuenta de que la asignaci\u00f3n es para el kernel y produce un error. Esto significa que el IOMMU a\u00fan almacena en cach\u00e9 estas entradas intermedias de la tabla de p\u00e1ginas, lo que convierte la vulnerabilidad descrita en una preocupaci\u00f3n real.\n\nDeshabilitar SVA en la arquitectura x86 hasta que el IOMMU pueda recibir notificaci\u00f3n para vaciar la cach\u00e9 de paginaci\u00f3n antes de liberar las p\u00e1ginas de la tabla de p\u00e1ginas del kernel de la CPU."
}
],
"id": "CVE-2025-71089",
"lastModified": "2026-06-17T10:03:38.367",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.1,
"impactScore": 6.0,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-71089",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-16T16:19:59.752068Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-01-13T16:16:08.583",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/240cd7f2812cc25496b12063d11c823618f364e9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/72f98ef9a4be30d2a60136dd6faee376f780d06c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7cad37e358970af1bb49030ff01f06a69fa7d985"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b34289505180a83607fcfdce14b5a290d0528476"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c2c3f1a3fd74ef16cf115f0c558616a13a8471b4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c341dee80b5df49a936182341b36395c831c2661"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-R6CC-J9RP-4F85
Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-02-26 21:31In the Linux kernel, the following vulnerability has been resolved:
iommu: disable SVA when CONFIG_X86 is set
Patch series "Fix stale IOTLB entries for kernel address space", v7.
This proposes a fix for a security vulnerability related to IOMMU Shared Virtual Addressing (SVA). In an SVA context, an IOMMU can cache kernel page table entries. When a kernel page table page is freed and reallocated for another purpose, the IOMMU might still hold stale, incorrect entries. This can be exploited to cause a use-after-free or write-after-free condition, potentially leading to privilege escalation or data corruption.
This solution introduces a deferred freeing mechanism for kernel page table pages, which provides a safe window to notify the IOMMU to invalidate its caches before the page is reused.
This patch (of 8):
In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware shares and walks the CPU's page tables. The x86 architecture maps the kernel's virtual address space into the upper portion of every process's page table. Consequently, in an SVA context, the IOMMU hardware can walk and cache kernel page table entries.
The Linux kernel currently lacks a notification mechanism for kernel page table changes, specifically when page table pages are freed and reused. The IOMMU driver is only notified of changes to user virtual address mappings. This can cause the IOMMU's internal caches to retain stale entries for kernel VA.
Use-After-Free (UAF) and Write-After-Free (WAF) conditions arise when kernel page table pages are freed and later reallocated. The IOMMU could misinterpret the new data as valid page table entries. The IOMMU might then walk into attacker-controlled memory, leading to arbitrary physical memory DMA access or privilege escalation. This is also a Write-After-Free issue, as the IOMMU will potentially continue to write Accessed and Dirty bits to the freed memory while attempting to walk the stale page tables.
Currently, SVA contexts are unprivileged and cannot access kernel mappings. However, the IOMMU will still walk kernel-only page tables all the way down to the leaf entries, where it realizes the mapping is for the kernel and errors out. This means the IOMMU still caches these intermediate page table entries, making the described vulnerability a real concern.
Disable SVA on x86 architecture until the IOMMU can receive notification to flush the paging cache before freeing the CPU kernel page table pages.
{
"affected": [],
"aliases": [
"CVE-2025-71089"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T16:16:08Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu: disable SVA when CONFIG_X86 is set\n\nPatch series \"Fix stale IOTLB entries for kernel address space\", v7.\n\nThis proposes a fix for a security vulnerability related to IOMMU Shared\nVirtual Addressing (SVA). In an SVA context, an IOMMU can cache kernel\npage table entries. When a kernel page table page is freed and\nreallocated for another purpose, the IOMMU might still hold stale,\nincorrect entries. This can be exploited to cause a use-after-free or\nwrite-after-free condition, potentially leading to privilege escalation or\ndata corruption.\n\nThis solution introduces a deferred freeing mechanism for kernel page\ntable pages, which provides a safe window to notify the IOMMU to\ninvalidate its caches before the page is reused.\n\n\nThis patch (of 8):\n\nIn the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware\nshares and walks the CPU\u0027s page tables. The x86 architecture maps the\nkernel\u0027s virtual address space into the upper portion of every process\u0027s\npage table. Consequently, in an SVA context, the IOMMU hardware can walk\nand cache kernel page table entries.\n\nThe Linux kernel currently lacks a notification mechanism for kernel page\ntable changes, specifically when page table pages are freed and reused. \nThe IOMMU driver is only notified of changes to user virtual address\nmappings. This can cause the IOMMU\u0027s internal caches to retain stale\nentries for kernel VA.\n\nUse-After-Free (UAF) and Write-After-Free (WAF) conditions arise when\nkernel page table pages are freed and later reallocated. The IOMMU could\nmisinterpret the new data as valid page table entries. The IOMMU might\nthen walk into attacker-controlled memory, leading to arbitrary physical\nmemory DMA access or privilege escalation. This is also a\nWrite-After-Free issue, as the IOMMU will potentially continue to write\nAccessed and Dirty bits to the freed memory while attempting to walk the\nstale page tables.\n\nCurrently, SVA contexts are unprivileged and cannot access kernel\nmappings. However, the IOMMU will still walk kernel-only page tables all\nthe way down to the leaf entries, where it realizes the mapping is for the\nkernel and errors out. This means the IOMMU still caches these\nintermediate page table entries, making the described vulnerability a real\nconcern.\n\nDisable SVA on x86 architecture until the IOMMU can receive notification\nto flush the paging cache before freeing the CPU kernel page table pages.",
"id": "GHSA-r6cc-j9rp-4f85",
"modified": "2026-02-26T21:31:26Z",
"published": "2026-01-13T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71089"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/240cd7f2812cc25496b12063d11c823618f364e9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72f98ef9a4be30d2a60136dd6faee376f780d06c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7cad37e358970af1bb49030ff01f06a69fa7d985"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b34289505180a83607fcfdce14b5a290d0528476"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2c3f1a3fd74ef16cf115f0c558616a13a8471b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c341dee80b5df49a936182341b36395c831c2661"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
MSRC_CVE-2025-71089
Vulnerability from csaf_microsoft - Published: 2026-01-02 00:00 - Updated: 2026-03-03 01:39OESA-2026-1863 (CVE-2025-68315)
Vulnerability from osv_openeuler – Published: 2026-04-11 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:
f2fs: fix to detect potential corrupted nid in free_nid_list
As reported, on-disk footer.ino and footer.nid is the same and out-of-range, let's add sanity check on f2fs_alloc_nid() to detect any potential corruption in free_nid_list.(CVE-2025-68315)
In the Linux kernel, the following vulnerability has been resolved:
ntfs3: Fix uninit buffer allocated by __getname()
Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.(CVE-2025-68727)
In the Linux kernel, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)
In the Linux kernel, the following vulnerability has been resolved:
uacce: fix cdev handling in the cleanup path
When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove.(CVE-2026-23096)
In the Linux kernel, the following vulnerability has been resolved:
bonding: fix use-after-free due to enslave fail after slave array update
Fix a use-after-free which happens due to enslave failure after the new slave has been added to the array. Since the new slave can be used for Tx immediately, we can use it after it has been freed by the enslave error cleanup path which frees the allocated slave memory. Slave update array is supposed to be called last when further enslave failures are not expected. Move it after xdp setup to avoid any problems.
It is very easy to reproduce the problem with a simple xdp_pass prog: ip l add bond1 type bond mode balance-xor ip l set bond1 up ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass ip l add dumdum type dummy
Then run in parallel: while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done; mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"
The crash happens almost immediately: [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf] [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary) [ 605.602979] Tainted: [B]=BAD_PAGE [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210 [ 605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89 [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213 [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000 [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000 [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84 [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000 [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0 [ 605.603373] Call Trace: [ 605.603392] <TASK> [ 605.603410] __dev_queue_xmit+0x448/0x32a0 [ 605.603434] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603461] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603484] ? __pfxdevqueue_xmit+0x10/0x10 [ 605.603507] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603546] ? _printk+0xcb/0x100 [ 605.603566] ? pfx__printk+0x10/0x10 [ 605.603589] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603627] ? add_taint+0x5e/0x70 [ 605.603648] ? add_taint+0x2a/0x70 [ 605.603670] ? end_report.cold+0x51/0x75 [ 605.603693] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603731] bond_start_xmit+0x623/0xc20 bonding
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fix use-after-free in nf_tables_addchain()
nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between.
This creates two use-after-free conditions:
1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it.
2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain.
Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.(CVE-2026-23231)
In the Linux kernel, the following vulnerability has been resolved:
tls: Fix race condition in tls_sw_cancel_work_tx()
This issue was discovered during a code audit.
After cancel_delayed_work_sync() is called from tls_sk_proto_close(), tx_work_handler() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the tx_work_handler() worker may dereference a freed TLS object.
The following is a simple race scenario:
cpu0 cpu1
tls_sk_proto_close() tls_sw_cancel_work_tx() tls_write_space() tls_sw_write_space() if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx->tx_bitmask)) set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask); cancel_delayed_work_sync(&ctx->tx_work.work); schedule_delayed_work(&tx_ctx->tx_work.work, 0);
To prevent this race condition, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync().(CVE-2026-23240)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_gate: snapshot parameters with RCU on replace
The gate action can be replaced while the hrtimer callback or dump path is walking the schedule list.
Convert the parameters to an RCU-protected snapshot and swap updates under tcf_lock, freeing the previous snapshot via call_rcu(). When REPLACE omits the entry list, preserve the existing schedule so the effective state is unchanged.(CVE-2026-23245)
In the Linux kernel, the following vulnerability has been resolved:
net: gro: fix outer network offset
The udp GRO complete stage assumes that all the packets inserted the RX
have the encapsulation flag zeroed. Such assumption is not true, as a
few H/W NICs can set such flag when H/W offloading the checksum for
an UDP encapsulated traffic, the tun driver can inject GSO packets with
UDP encapsulation and the problematic layout can also be created via
a veth based setup.
Due to the above, in the problematic scenarios, udp4_gro_complete() uses the wrong network offset (inner instead of outer) to compute the outer UDP header pseudo checksum, leading to csum validation errors later on in packet processing.
Address the issue always clearing the encapsulation flag at GRO completion time. Such flag will be set again as needed for encapsulated packets by udp_gro_complete().(CVE-2026-23254)
In the Linux kernel, the following vulnerability has been resolved:
net: add proper RCU protection to /proc/net/ptype
Yin Fengwei reported an RCU stall in ptype_seq_show() and provided a patch.
Real issue is that ptype_seq_next() and ptype_seq_show() violate RCU rules.
ptype_seq_show() runs under rcu_read_lock(), and reads pt->dev to get device name without any barrier.
At the same time, concurrent writers can remove a packet_type structure (which is correctly freed after an RCU grace period) and clear pt->dev without an RCU grace period.
Define ptype_iter_state to carry a dev pointer along seq_net_private:
struct ptype_iter_state { struct seq_net_private p; struct net_device *dev; // added in this patch };
We need to record the device pointer in ptype_get_idx() and ptype_seq_next() so that ptype_seq_show() is safe against concurrent pt->dev changes.
We also need to add full RCU protection in ptype_seq_next(). (Missing READ_ONCE() when reading list.next values)
Many thanks to Dong Chenchen for providing a repro.(CVE-2026-23255)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocks
As Paolo said earlier [1]:
"Since the blamed commit below, classify can return TC_ACT_CONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet."
act_ct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing act_ct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach act_ct to egress (albeit only with clsact).
[1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/ [2] https://lore.kernel.org/netdev/(CVE-2026-23270)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels
IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer.
If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1.
Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.(CVE-2026-23274)
In the Linux kernel, the following vulnerability has been resolved:
net: add xmit recursion limit to tunnel xmit functions
Tunnel xmit functions (iptunnel_xmit, ip6tunnel_xmit) lack their own recursion limit. When a bond device in broadcast mode has GRE tap interfaces as slaves, and those GRE tunnels route back through the bond, multicast/broadcast traffic triggers infinite recursion between bond_xmit_broadcast() and ip_tunnel_xmit()/ip6_tnl_xmit(), causing kernel stack overflow.
The existing XMIT_RECURSION_LIMIT (8) in the no-qdisc path is not sufficient because tunnel recursion involves route lookups and full IP output, consuming much more stack per level. Use a lower limit of 4 (IP_TUNNEL_RECURSION_LIMIT) to prevent overflow.
Add recursion detection using dev_xmit_recursion helpers directly in iptunnel_xmit() and ip6tunnel_xmit() to cover all IPv4/IPv6 tunnel paths including UDP encapsulated tunnels (VXLAN, Geneve, etc.).
Move dev_xmit_recursion helpers from net/core/dev.h to public header include/linux/netdevice.h so they can be used by tunnel code.
BUG: KASAN: stack-out-of-bounds in blake2s.constprop.0+0xe7/0x160 Write of size 32 at addr ffff88810033fed0 by task kworker/0:1/11 Workqueue: mld mld_ifc_work Call Trace: <TASK> __build_flow_key.constprop.0 (net/ipv4/route.c:515) ip_rt_update_pmtu (net/ipv4/route.c:1073) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:84) ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) ip_finish_output2 (net/ipv4/ip_output.c:237) ip_output (net/ipv4/ip_output.c:438) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) ip_finish_output2 (net/ipv4/ip_output.c:237) ip_output (net/ipv4/ip_output.c:438) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86) ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) gre_tap_xmit (net/ipv4/ip_gre.c:779) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279) bond_start_xmit (drivers/net/bonding/bond_main.c:5530) dev_hard_start_xmit (net/core/dev.c:3887) __dev_queue_xmit (net/core/dev.c:4841) mld_sendpack mld_ifc_work process_one_work worker_thread </TASK>(CVE-2026-23276)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit
teql_master_xmit() calls netdev_start_xmit(skb, slave) to transmit through slave devices, but does not update skb->dev to the slave device beforehand.
When a gretap tunnel is a TEQL slave, the transmit path reaches iptunnel_xmit() which saves dev = skb->dev (still pointing to teql0 master) and later calls iptunnel_xmit_stats(dev, pkt_len). This function does:
get_cpu_ptr(dev->tstats)
Since teql_master_setup() does not set dev->pcpu_stat_type to NETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstats for teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computes NULL + __per_cpu_offset[cpu], resulting in a page fault.
BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: <TASK> ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206)
Fix this by setting skb->dev = slave before calling netdev_start_xmit(), so that tunnel xmit functions see the correct slave device with properly allocated tstats.(CVE-2026-23277)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: always walk all pending catchall elements
During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch.
If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate.
Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 ..
In the Linux kernel, the following vulnerability has been resolved:
net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled
When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. If an IPv6 packet is injected into the interface, route_shortcircuit() is called and a NULL pointer dereference happens on neigh_lookup().
BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Call Trace: <TASK> vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Fix this by adding an early check on route_shortcircuit() when protocol is ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here because VXLAN can be built-in even when IPv6 is built as a module.(CVE-2026-23293)
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop
When a standalone IPv6 nexthop object is created with a loopback device (e.g., "ip -6 nexthop add id 100 dev lo"), fib6_nh_init() misclassifies it as a reject route. This is because nexthop objects have no destination prefix (fc_dst=::), causing fib6_is_reject() to match any loopback nexthop. The reject path skips fib_nh_common_init(), leaving nhc_pcpu_rth_output unallocated. If an IPv4 route later references this nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and panics.
Simplify the check in fib6_nh_init() to only match explicit reject routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback promotion heuristic in fib6_is_reject() is handled separately by ip6_route_info_create_nh(). After this change, the three cases behave as follows:
-
Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"): RTF_REJECT is set, enters reject path, skips fib_nh_common_init(). No behavior change.
-
Implicit loopback reject route ("ip -6 route add 2001:db8::/32 dev lo"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. ip6_route_info_create_nh() still promotes it to reject afterward. nhc_pcpu_rth_output is allocated but unused, which is harmless.
-
Standalone nexthop object ("ip -6 nexthop add id 100 dev lo"): RTF_REJECT is not set, takes normal path, fib_nh_common_init() is called. nhc_pcpu_rth_output is properly allocated, fixing the crash when IPv4 routes reference this nexthop.(CVE-2026-23300)
In the Linux kernel, the following vulnerability has been resolved:
net: annotate data-races around sk->sk_{data_ready,write_space}
skmsg (and probably other layers) are changing these pointers while other cpus might read them concurrently.
Add corresponding READ_ONCE()/WRITE_ONCE() annotations for UDP, TCP and AF_UNIX.(CVE-2026-23302)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Don't log plaintext credentials in cifs_set_cifscreds
When debug logging is enabled, cifs_set_cifscreds() logs the key payload and exposes the plaintext username and password. Remove the debug log to avoid exposing credentials.(CVE-2026-23303)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()
l3mdev_master_dev_rcu() can return NULL when the slave device is being un-slaved from a VRF. All other callers deal with this, but we lost the fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu() with commit 4832c30d5458 ("net: ipv6: put host and anycast routes on device with address").
KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) Call Trace: ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437)
I was tempted to rework the un-slaving code to clear the flag first and insert synchronize_rcu() before we remove the upper. But looks like the explicit fallback to loopback_dev is an established pattern. And I guess avoiding the synchronize_rcu() is nice, too.(CVE-2026-23304)
In the Linux kernel, the following vulnerability has been resolved:
bpf/bonding: reject vlan+srcmac xmit_hash_policy change when XDP is loaded
bond_option_mode_set() already rejects mode changes that would make a loaded XDP program incompatible via bond_xdp_check(). However, bond_option_xmit_hash_policy_set() has no such guard.
For 802.3ad and balance-xor modes, bond_xdp_check() returns false when xmit_hash_policy is vlan+srcmac, because the 802.1q payload is usually absent due to hardware offload. This means a user can:
- Attach a native XDP program to a bond in 802.3ad/balance-xor mode with a compatible xmit_hash_policy (e.g. layer2+3).
- Change xmit_hash_policy to vlan+srcmac while XDP remains loaded.
This leaves bond->xdp_prog set but bond_xdp_check() now returning false for the same device. When the bond is later destroyed, dev_xdp_uninstall() calls bond_xdp_set(dev, NULL, NULL) to remove the program, which hits the bond_xdp_check() guard and returns -EOPNOTSUPP, triggering:
WARN_ON(dev_xdp_install(dev, mode, bpf_op, NULL, 0, NULL))
Fix this by rejecting xmit_hash_policy changes to vlan+srcmac when an XDP program is loaded on a bond in 802.3ad or balance-xor mode.
commit 39a0876d595b ("net, bonding: Disallow vlan+srcmac with XDP") introduced bond_xdp_check() which returns false for 802.3ad/balance-xor modes when xmit_hash_policy is vlan+srcmac. The check was wired into bond_xdp_set() to reject XDP attachment with an incompatible policy, but the symmetric path -- preventing xmit_hash_policy from being changed to an incompatible value after XDP is already loaded -- was left unguarded in bond_option_xmit_hash_policy_set().
Note: commit 094ee6017ea0 ("bonding: check xdp prog when set bond mode") later added a similar guard to bond_option_mode_set(), but bond_option_xmit_hash_policy_set() remained unprotected.(CVE-2026-23310)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: in-kernel: always mark signal+subflow endp as used
Syzkaller managed to find a combination of actions that was generating this warning:
msk->pm.local_addr_used == 0 WARNING: net/mptcp/pm_kernel.c:1071 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210, CPU#1: syz.2.17/961 Modules linked in: CPU: 1 UID: 0 PID: 961 Comm: syz.2.17 Not tainted 6.19.0-08368-gfafda3b4b06b #22 PREEMPT(full) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.17.0-debian-1.17.0-1build1 04/01/2014 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline] RIP: 0010:mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline] RIP: 0010:mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210 Code: 89 c5 e8 46 30 6f fe e9 21 fd ff ff 49 83 ed 80 e8 38 30 6f fe 4c 89 ef be 03 00 00 00 e8 db 49 df fe eb ac e8 24 30 6f fe 90 <0f> 0b 90 e9 1d ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a RSP: 0018:ffffc90001663880 EFLAGS: 00010293 RAX: ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff R10: ffffffff82de18ba R11: 0000000000000000 R12: ffff88800641a640 R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650 FS: 00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0 Call Trace: <TASK> genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x4aa/0x5b0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xc9/0xf0 net/socket.c:742 _syssendmsg+0x272/0x3b0 net/socket.c:2592 _sys_sendmsg+0x2de/0x320 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x143/0x440 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f66346f826d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc83d8bdc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6634985fa0 RCX: 00007f66346f826d RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6634985fa8 R13: 00007f6634985fac R14: 0000000000000000 R15: 0000000000001770 </TASK>
The actions that caused that seem to be:
- Set the MPTCP subflows limit to 0
- Create an MPTCP endpoint with both the 'signal' and 'subflow' flags
- Create a new MPTCP connection from a different address: an ADD_ADDR linked to the MPTCP endpoint will be sent ('signal' flag), but no subflows is initiated ('subflow' flag)
- Remove the MPTCP endpoint
---truncated---(CVE-2026-23321)
In the Linux kernel, the following vulnerability has been resolved:
xdp: produce a warning when calculated tailroom is negative
Many ethernet drivers report xdp Rx queue frag size as being the same as DMA write size. However, the only user of this field, namely bpf_xdp_frags_increase_tail(), clearly expects a truesize.
Such difference leads to unspecific memory corruption issues under certain circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when running xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses all DMA-writable space in 2 buffers. This would be fine, if only rxq->frag_size was properly set to 4K, but value of 3K results in a negative tailroom, because there is a non-zero page offset.
We are supposed to return -EINVAL and be done with it in such case, but due to tailroom being stored as an unsigned int, it is reported to be somewhere near UINT_MAX, resulting in a tail being grown, even if the requested offset is too much (it is around 2K in the abovementioned test). This later leads to all kinds of unspecific calltraces.
[ 7340.337579] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6 [ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4 [ 7340.338179] in libc.so.6[61c9d,7f4161aaf000+160000] [ 7340.339230] in xskxceiver[42b5,400000+69000] [ 7340.340300] likely on CPU 6 (core 0, socket 6) [ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 <4c> 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe [ 7340.340888] likely on CPU 3 (core 0, socket 3) [ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff <8b> 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7 [ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d255010bdffc: 0000 [#1] SMP NOPTI [ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy) [ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 [ 7340.409716] RIP: 0010:lookup_swap_cgroup_id+0x44/0x80 [ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89 [ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202 [ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010 [ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff [ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0 [ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0 [ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500 [ 7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000 [ 7340.419489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0 [ 7340.421237] PKRU: 55555554 [ 7340.421623] Call Trace: [ 7340.421987] <TASK> [ 7340.422309] ? softleaf_from_pte+0x77/0xa0 [ 7340.422855] swap_pte_batch+0xa7/0x290 [ 7340.423363] zap_nonpresent_ptes.constprop.0.isra.0+0xd1/0x270 [ 7340.424102] zap_pte_range+0x281/0x580 [ 7340.424607] zap_pmd_range.isra.0+0xc9/0x240 [ 7340.425177] unmap_page_range+0x24d/0x420 [ 7340.425714] unmap_vmas+0xa1/0x180 [ 7340.426185] exit_mmap+0xe1/0x3b0 [ 7340.426644] __mmput+0x41/0x150 [ 7340.427098] exit_mm+0xb1/0x110 [ 7340.427539] do_exit+0x1b2/0x460 [ 7340.427992] do_group_exit+0x2d/0xc0 [ 7340.428477] get_signal+0x79d/0x7e0 [ 7340.428957] arch_do_signal_or_restart+0x34/0x100 [ 7340.429571] exit_to_user_mode_loop+0x8e/0x4c0 [ 7340.430159] do_syscall_64+0x188/ ---truncated---(CVE-2026-23343)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: split gc into unlink and reclaim phase
Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service).
We must split GC in an unlink and a reclaim phase.
We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure.
call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version.
This a similar approach as done recently for the rbtree backend in commit 35f83a75529a ("netfilter: nft_set_rbtree: don't gc elements on insert").(CVE-2026-23351)
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: fix locking for bcm_op runtime updates
Commit c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates") added a locking for some variables that can be modified at runtime when updating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup().
Usually the RX_SETUP only handles and filters incoming traffic with one exception: When the RX_RTR_FRAME flag is set a predefined CAN frame is sent when a specific RTR frame is received. Therefore the rx bcm_op uses bcm_can_tx() which uses the bcm_tx_lock that was only initialized in bcm_tx_setup(). Add the missing spin_lock_init() when allocating the bcm_op in bcm_rx_setup() to handle the RTR case properly.(CVE-2026-23362)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: kalmia: validate USB endpoints
The kalmia driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.(CVE-2026-23365)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: register phy led_triggers during probe to avoid AB-BA deadlock
There is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and LED_TRIGGER_PHY are enabled:
[ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc <-- Trying to get lock "triggers_list_lock" via down_write(&triggers_list_lock); [ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234 [ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c [ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c [ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0 [ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0 [ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c [ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78 [ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654 <-- Hold lock "rtnl_mutex" by calling rtnl_lock(); [ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0 [ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c [ 1362.104022] [<80014504>] syscall_common+0x34/0x58
Here LED_TRIGGER_PHY is registering LED triggers during phy_attach while holding RTNL and then taking triggers_list_lock.
[ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168 <-- Trying to get lock "rtnl_mutex" via rtnl_lock(); [ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4 [ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360 <-- Hold lock "triggers_list_lock" by down_read(&triggers_list_lock); [ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c [ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc [ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c [ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4 [ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c [ 1362.232164] [<80014504>] syscall_common+0x34/0x58
Here LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takes triggers_list_lock and then RTNL. A classical AB-BA deadlock.
phy_led_triggers_registers() does not require the RTNL, it does not make any calls into the network stack which require protection. There is also no requirement the PHY has been attached to a MAC, the triggers only make use of phydev state. This allows the call to phy_led_triggers_registers() to be placed elsewhere. PHY probe() and release() don't hold RTNL, so solving the AB-BA deadlock.(CVE-2026-23368)
In the Linux kernel, the following vulnerability has been resolved:
sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting
Running stress-ng --schedpolicy 0 on an RT kernel on a big machine might lead to the following WARNINGs (edited).
sched: DL de-boosted task PID 22725: REPLENISH flag missing
WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8 ... (running_bw underflow) Call trace: dequeue_task_dl+0x15c/0x1f8 (P) dequeue_task+0x80/0x168 deactivate_task+0x24/0x50 push_dl_task+0x264/0x2e0 dl_task_timer+0x1b0/0x228 __hrtimer_run_queues+0x188/0x378 hrtimer_interrupt+0xfc/0x260 ...
The problem is that when a SCHED_DEADLINE task (lock holder) is changed to a lower priority class via sched_setscheduler(), it may fail to properly inherit the parameters of potential DEADLINE donors if it didn't already inherit them in the past (shorter deadline than donor's at that time). This might lead to bandwidth accounting corruption, as enqueue_task_dl() won't recognize the lock holder as boosted.
The scenario occurs when: 1. A DEADLINE task (donor) blocks on a PI mutex held by another DEADLINE task (holder), but the holder doesn't inherit parameters (e.g., it already has a shorter deadline) 2. sched_setscheduler() changes the holder from DEADLINE to a lower class while still holding the mutex 3. The holder should now inherit DEADLINE parameters from the donor and be enqueued with ENQUEUE_REPLENISH, but this doesn't happen
Fix the issue by introducing __setscheduler_dl_pi(), which detects when a DEADLINE (proper or boosted) task gets setscheduled to a lower priority class. In case, the function makes the task inherit DEADLINE parameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag to ensure proper bandwidth accounting during the next enqueue operation.(CVE-2026-23371)
In the Linux kernel, the following vulnerability has been resolved:
mm: thp: deny THP for files on anonymous inodes
file_thp_enabled() incorrectly allows THP for files on anonymous inodes (e.g. guest_memfd and secretmem). These files are created via alloc_file_pseudo(), which does not call get_write_access() and leaves inode->i_writecount at 0. Combined with S_ISREG(inode->i_mode) being true, they appear as read-only regular files when CONFIG_READ_ONLY_THP_FOR_FS is enabled, making them eligible for THP collapse.
Anonymous inodes can never pass the inode_is_open_for_write() check since their i_writecount is never incremented through the normal VFS open path. The right thing to do is to exclude them from THP eligibility altogether, since CONFIG_READ_ONLY_THP_FOR_FS was designed for real filesystem files (e.g. shared libraries), not for pseudo-filesystem inodes.
For guest_memfd, this allows khugepaged and MADV_COLLAPSE to create large folios in the page cache via the collapse path, but the guest_memfd fault handler does not support large folios. This triggers WARN_ON_ONCE(folio_test_large(folio)) in kvm_gmem_fault_user_mapping().
For secretmem, collapse_file() tries to copy page contents through the direct map, but secretmem pages are removed from the direct map. This can result in a kernel crash:
BUG: unable to handle page fault for address: ffff88810284d000
RIP: 0010:memcpy_orig+0x16/0x130
Call Trace:
collapse_file
hpage_collapse_scan_file
madvise_collapse
Secretmem is not affected by the crash on upstream as the memory failure recovery handles the failed copy gracefully, but it still triggers confusing false memory failure reports:
Memory failure: 0x106d96f: recovery action for clean unevictable
LRU page: Recovered
Check IS_ANON_FILE(inode) in file_thp_enabled() to deny THP for all anonymous inode files.(CVE-2026-23375)
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled
When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. Then, if neigh_suppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will dereference ipv6_stub->nd_tbl which is NULL, passing it to neigh_lookup(). This causes a kernel NULL pointer dereference.
BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neigh_lookup+0x16/0xe0 [...] Call Trace: <IRQ> ? neigh_lookup+0x16/0xe0 br_do_suppress_nd+0x160/0x290 [bridge] br_handle_frame_finish+0x500/0x620 [bridge] br_handle_frame+0x353/0x440 [bridge] __netif_receive_skb_core.constprop.0+0x298/0x1110 __netif_receive_skb_one_core+0x3d/0xa0 process_backlog+0xa0/0x140 __napi_poll+0x2c/0x170 net_rx_action+0x2c4/0x3a0 handle_softirqs+0xd0/0x270 do_softirq+0x3f/0x60
Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled.(CVE-2026-23381)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_CT: drop pending enqueued packets on template removal
Templates refer to objects that can go away while packets are sitting in nfqueue refer to:
- helper, this can be an issue on module removal.
- timeout policy, nfnetlink_cttimeout might remove it.
The use of templates with zone and event cache filter are safe, since this just copies values.
Flush these enqueued packets in case the template rule gets removed.(CVE-2026-23391)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: release flowtable after rcu grace period on error
Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane.
This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu().
There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised.
Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.(CVE-2026-23392)
In the Linux kernel, the following vulnerability has been resolved:
bridge: cfm: Fix race condition in peer_mep deletion
When a peer MEP is being deleted, cancel_delayed_work_sync() is called on ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs in softirq context under rcu_read_lock (without RTNL) and can re-schedule ccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync() returning and kfree_rcu() being called.
The following is a simple race scenario:
cpu0 cpu1
mep_delete_implementation() cancel_delayed_work_sync(ccm_rx_dwork); br_cfm_frame_rx() // peer_mep still in hlist if (peer_mep->ccm_defect) ccm_rx_timer_start() queue_delayed_work(ccm_rx_dwork) hlist_del_rcu(&peer_mep->head); kfree_rcu(peer_mep, rcu); ccm_rx_work_expired() // on freed peer_mep
To prevent this, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync() in both peer MEP deletion paths, so that subsequent queue_delayed_work() calls from br_cfm_frame_rx() are silently rejected.
The cc_peer_disable() helper retains cancel_delayed_work_sync() because it is also used for the CC enable/disable toggle path where the work must remain re-schedulable.(CVE-2026-23393)
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Give up GC if MSG_PEEK intervened.
Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro.
This is the exact same issue previously fixed by commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK").
After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue.
The problem is that MSG_PEEK bumps a file refcount without interacting with GC.
Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B.
The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B.
GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2
close(sk-B)
-> sk-B's file refcount : 2 -> 1
unix_vertex_dead(sk-B) -> true
Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds.
However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation.
At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former.
Finally, GC incorrectly concludes that both sk-A and sk-B are dead.
One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm.
The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection.
When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC.
Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC.
Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run.
This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily.
Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.(CVE-2026-23394)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ
Currently the code attempts to accept requests regardless of the command identifier which may cause multiple requests to be marked as pending (FLAG_DEFER_SETUP) which can cause more than L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer causing an overflow.
The spec is quite clear that the same identifier shall not be used on subsequent requests:
'Within each signaling channel a different Identifier shall be used for each successive request or indication.' https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d
So this attempts to check if there are any channels pending with the same identifier and rejects if any are found.(CVE-2026-23395)
In the Linux kernel, the following vulnerability has been resolved:
nfnetlink_osf: validate individual option lengths in fingerprints
nfnl_osf_add_callback() validates opt_num bounds and string NUL-termination but does not check individual option length fields. A zero-length option causes nf_osf_match_one() to enter the option matching loop even when foptsize sums to zero, which matches packets with no TCP options where ctx->optp is NULL:
Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:227) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:293) nf_hook_slow (net/netfilter/core.c:623) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573)
Additionally, an MSS option (kind=2) with length < 4 causes out-of-bounds reads when nf_osf_match_one() unconditionally accesses optp[2] and optp[3] for MSS value extraction. While RFC 9293 section 3.2 specifies that the MSS option is always exactly 4 bytes (Kind=2, Length=4), the check uses "< 4" rather than "!= 4" because lengths greater than 4 do not cause memory safety issues -- the buffer is guaranteed to be at least foptsize bytes by the ctx->optsize == foptsize check.
Reject fingerprints where any option has zero length, or where an MSS option has length less than 4, at add time rather than trusting these values in the packet matching hot path.(CVE-2026-23397)
In the Linux kernel, the following vulnerability has been resolved:
nf_tables: nft_dynset: fix possible stateful expression memleak in error path
If cloning the second stateful expression in the element via GFP_ATOMIC fails, then the first stateful expression remains in place without being released.
unreferenced object (percpu) 0x607b97e9cab8 (size 16): comm "softirq", pid 0, jiffies 4294931867 hex dump (first 16 bytes on cpu 3): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace (crc 0): pcpu_alloc_noprof+0x453/0xd80 nft_counter_clone+0x9c/0x190 [nf_tables] nft_expr_clone+0x8f/0x1b0 [nf_tables] nft_dynset_new+0x2cb/0x5f0 [nf_tables] nft_rhash_update+0x236/0x11c0 [nf_tables] nft_dynset_eval+0x11f/0x670 [nf_tables] nft_do_chain+0x253/0x1700 [nf_tables] nft_do_chain_ipv4+0x18d/0x270 [nf_tables] nf_hook_slow+0xaa/0x1e0 ip_local_deliver+0x209/0x330(CVE-2026-23399)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE
When installing an emulated MMIO SPTE, do so after dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a guest write, it failed to account for writes to guest memory that are outside the scope of KVM.
E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE.
------------[ cut here ]------------ is_shadow_present_pte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292 Modules linked in: kvm_intel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm] Call Trace: <TASK> mmu_set_spte+0x237/0x440 [kvm] ept_page_fault+0x535/0x7f0 [kvm] kvm_mmu_do_page_fault+0xee/0x1f0 [kvm] kvm_mmu_page_fault+0x8d/0x620 [kvm] vmx_handle_exit+0x18c/0x5a0 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0x730 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x47fa3f </TASK> ---[ end trace 0000000000000000 ]---(CVE-2026-23401)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix memory leak in verify_header
The function sets *ns = NULL on every call, leaking the namespace
string allocated in previous iterations when multiple profiles are
unpacked. This also breaks namespace consistency checking since *ns
is always NULL when the comparison is made.
Remove the incorrect assignment. The caller (aa_unpack) initializes *ns to NULL once before the loop, which is sufficient.(CVE-2026-23403)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: replace recursive profile removal with iterative approach
The profile removal code uses recursion when removing nested profiles, which can lead to kernel stack exhaustion and system crashes.
Reproducer: $ pf='a'; for ((i=0; i<1024; i++)); do echo -e "profile $pf { \n }" | apparmor_parser -K -a; pf="$pf//x"; done $ echo -n a > /sys/kernel/security/apparmor/.remove
Replace the recursive __aa_profile_list_release() approach with an iterative approach in __remove_profile(). The function repeatedly finds and removes leaf profiles until the entire subtree is removed, maintaining the same removal semantic without recursion.(CVE-2026-23404)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix: limit the number of levels of policy namespaces
Currently the number of policy namespaces is not bounded relying on the user namespace limit. However policy namespaces aren't strictly tied to user namespaces and it is possible to create them and nest them arbitrarily deep which can be used to exhaust system resource.
Hard cap policy namespaces to the same depth as user namespaces.(CVE-2026-23405)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: Fix double free of ns_name in aa_replace_profiles()
if ns_name is NULL after 1071 error = aa_unpack(udata, &lh, &ns_name);
and if ent->ns_name contains an ns_name in 1089 } else if (ent->ns_name) {
then ns_name is assigned the ent->ns_name 1095 ns_name = ent->ns_name;
however ent->ns_name is freed at 1262 aa_load_ent_free(ent);
and then again when freeing ns_name at 1270 kfree(ns_name);
Fix this by NULLing out ent->ns_name after it is transferred to ns_name
")(CVE-2026-23408)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix differential encoding verification
Differential encoding allows loops to be created if it is abused. To prevent this the unpack should verify that a diff-encode chain terminates.
Unfortunately the differential encode verification had two bugs.
-
it conflated states that had gone through check and already been marked, with states that were currently being checked and marked. This means that loops in the current chain being verified are treated as a chain that has already been verified.
-
the order bailout on already checked states compared current chain check iterators j,k instead of using the outer loop iterator i. Meaning a step backwards in states in the current chain verification was being mistaken for moving to an already verified state.
Move to a double mark scheme where already verified states get a different mark, than the current chain being kept. This enables us to also drop the backwards verification check that was the cause of the second error as any already verified state is already marked.(CVE-2026-23409)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix race on rawdata dereference
There is a race condition that leads to a use-after-free situation: because the rawdata inodes are not refcounted, an attacker can start open()ing one of the rawdata files, and at the same time remove the last reference to this rawdata (by removing the corresponding profile, for example), which frees its struct aa_loaddata; as a result, when seq_rawdata_open() is reached, i_private is a dangling pointer and freed memory is accessed.
The rawdata inodes weren't refcounted to avoid a circular refcount and were supposed to be held by the profile rawdata reference. However during profile removal there is a window where the vfs and profile destruction race, resulting in the use after free.
Fix this by moving to a double refcount scheme. Where the profile refcount on rawdata is used to break the circular dependency. Allowing for freeing of the rawdata once all inode references to the rawdata are put.(CVE-2026-23410)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix race between freeing data and fs accessing it
AppArmor was putting the reference to i_private data on its end after removing the original entry from the file system. However the inode can aand does live beyond that point and it is possible that some of the fs call back functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs.
While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private.
Fix this by moving the put of i_private referenced data to the correct place which is during inode eviction.(CVE-2026-23411)
In the Linux kernel, the following vulnerability has been resolved:
clsact: Fix use-after-free in init/destroy rollback asymmetry
Fix a use-after-free in the clsact qdisc upon init/destroy rollback asymmetry. The latter is achieved by first fully initializing a clsact instance, and then in a second step having a replacement failure for the new clsact qdisc instance. clsact_init() initializes ingress first and then takes care of the egress part. This can fail midway, for example, via tcf_block_get_ext(). Upon failure, the kernel will trigger the clsact_destroy() callback.
Commit 1cb6f0bae504 ("bpf: Fix too early release of tcx_entry") details the way how the transition is happening. If tcf_block_get_ext on the q->ingress_block ends up failing, we took the tcx_miniq_inc reference count on the ingress side, but not yet on the egress side. clsact_destroy() tests whether the {ingress,egress}_entry was non-NULL. However, even in midway failure on the replacement, both are in fact non-NULL with a valid egress_entry from the previous clsact instance.
What we really need to test for is whether the qdisc instance-specific ingress or egress side previously got initialized. This adds a small helper for checking the miniq initialization called mini_qdisc_pair_inited, and utilizes that upon clsact_destroy() in order to fix the use-after-free scenario. Convert the ingress_destroy() side as well so both are consistent to each other.(CVE-2026-23413)
In the Linux kernel, the following vulnerability has been resolved:
tls: Purge async_hold in tls_decrypt_async_wait()
The async_hold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. Once tls_decrypt_async_wait() returns, every AEAD operation has completed and the engine no longer references those skbs, so they can be freed unconditionally.
A subsequent patch adds batch async decryption to tls_sw_read_sock(), introducing a new call site that must drain pending AEAD operations and release held skbs. Move __skb_queue_purge(&ctx->async_hold) into tls_decrypt_async_wait() so the purge is centralized and every caller -- recvmsg's drain path, the -EBUSY fallback in tls_do_decryption(), and the new read_sock batch path -- releases held skbs on synchronization without each site managing the purge independently.
This fixes a leak when tls_strp_msg_hold() fails part-way through, after having added some cloned skbs to the async_hold queue. tls_decrypt_sg() will then call tls_decrypt_async_wait() to process all pending decrypts, and drop back to synchronous mode, but tls_sw_recvmsg() only flushes the async_hold queue when one record has been processed in "fully-async" mode, which may not be the case here.
[(CVE-2026-23414)
In the Linux kernel, the following vulnerability has been resolved:
xen/privcmd: restrict usage in unprivileged domU
The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains.
In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature.
The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest.
Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today.
The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot.
This is XSA-482
V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)(CVE-2026-31788)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"perf-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.2.142.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.0.2.142.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"perf-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-145.0.2.142.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.2.142.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.2.142.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to detect potential corrupted nid in free_nid_list\n\nAs reported, on-disk footer.ino and footer.nid is the same and\nout-of-range, let\u0026apos;s add sanity check on f2fs_alloc_nid() to detect\nany potential corruption in free_nid_list.(CVE-2025-68315)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs3: Fix uninit buffer allocated by __getname()\n\nFix uninit errors caused after buffer allocation given to \u0026apos;de\u0026apos;; by\ninitializing the buffer with zeroes. The fix was found by using KMSAN.(CVE-2025-68727)\n\nIn the Linux kernel, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuacce: fix cdev handling in the cleanup path\n\nWhen cdev_device_add fails, it internally releases the cdev memory,\nand if cdev_device_del is then executed, it will cause a hang error.\nTo fix it, we check the return value of cdev_device_add() and clear\nuacce-\u0026gt;cdev to avoid calling cdev_device_del in the uacce_remove.(CVE-2026-23096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbonding: fix use-after-free due to enslave fail after slave array update\n\nFix a use-after-free which happens due to enslave failure after the new\nslave has been added to the array. Since the new slave can be used for Tx\nimmediately, we can use it after it has been freed by the enslave error\ncleanup path which frees the allocated slave memory. Slave update array is\nsupposed to be called last when further enslave failures are not expected.\nMove it after xdp setup to avoid any problems.\n\nIt is very easy to reproduce the problem with a simple xdp_pass prog:\n ip l add bond1 type bond mode balance-xor\n ip l set bond1 up\n ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass\n ip l add dumdum type dummy\n\nThen run in parallel:\n while :; do ip l set dumdum master bond1 1\u0026gt;/dev/null 2\u0026gt;\u0026amp;1; done;\n mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp \u0026quot;dp=1-1023, flags=syn\u0026quot;\n\nThe crash happens almost immediately:\n [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI\n [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf]\n [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary)\n [ 605.602979] Tainted: [B]=BAD_PAGE\n [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n [ 605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210\n [ 605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89\n [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213\n [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000\n [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be\n [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c\n [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000\n [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84\n [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000\n [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0\n [ 605.603373] Call Trace:\n [ 605.603392] \u0026lt;TASK\u0026gt;\n [ 605.603410] __dev_queue_xmit+0x448/0x32a0\n [ 605.603434] ? __pfx_vprintk_emit+0x10/0x10\n [ 605.603461] ? __pfx_vprintk_emit+0x10/0x10\n [ 605.603484] ? __pfx___dev_queue_xmit+0x10/0x10\n [ 605.603507] ? bond_start_xmit+0xbfb/0xc20 [bonding]\n [ 605.603546] ? _printk+0xcb/0x100\n [ 605.603566] ? __pfx__printk+0x10/0x10\n [ 605.603589] ? bond_start_xmit+0xbfb/0xc20 [bonding]\n [ 605.603627] ? add_taint+0x5e/0x70\n [ 605.603648] ? add_taint+0x2a/0x70\n [ 605.603670] ? end_report.cold+0x51/0x75\n [ 605.603693] ? bond_start_xmit+0xbfb/0xc20 [bonding]\n [ 605.603731] bond_start_xmit+0x623/0xc20 [bonding](CVE-2026-23171)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: fix use-after-free in nf_tables_addchain()\n\nnf_tables_addchain() publishes the chain to table-\u0026gt;chains via\nlist_add_tail_rcu() (in nft_chain_add()) before registering hooks.\nIf nf_tables_register_hook() then fails, the error path calls\nnft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy()\nwith no RCU grace period in between.\n\nThis creates two use-after-free conditions:\n\n 1) Control-plane: nf_tables_dump_chains() traverses table-\u0026gt;chains\n under rcu_read_lock(). A concurrent dump can still be walking\n the chain when the error path frees it.\n\n 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly\n installs the IPv4 hook before IPv6 registration fails. Packets\n entering nft_do_chain() via the transient IPv4 hook can still be\n dereferencing chain-\u0026gt;blob_gen_X when the error path frees the\n chain.\n\nAdd synchronize_rcu() between nft_chain_del() and the chain destroy\nso that all RCU readers -- both dump threads and in-flight packet\nevaluation -- have finished before the chain is freed.(CVE-2026-23231)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntls: Fix race condition in tls_sw_cancel_work_tx()\n\nThis issue was discovered during a code audit.\n\nAfter cancel_delayed_work_sync() is called from tls_sk_proto_close(),\ntx_work_handler() can still be scheduled from paths such as the\nDelayed ACK handler or ksoftirqd.\nAs a result, the tx_work_handler() worker may dereference a freed\nTLS object.\n\nThe following is a simple race scenario:\n\n cpu0 cpu1\n\ntls_sk_proto_close()\n tls_sw_cancel_work_tx()\n tls_write_space()\n tls_sw_write_space()\n if (!test_and_set_bit(BIT_TX_SCHEDULED, \u0026amp;tx_ctx-\u0026gt;tx_bitmask))\n set_bit(BIT_TX_SCHEDULED, \u0026amp;ctx-\u0026gt;tx_bitmask);\n cancel_delayed_work_sync(\u0026amp;ctx-\u0026gt;tx_work.work);\n schedule_delayed_work(\u0026amp;tx_ctx-\u0026gt;tx_work.work, 0);\n\nTo prevent this race condition, cancel_delayed_work_sync() is\nreplaced with disable_delayed_work_sync().(CVE-2026-23240)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_gate: snapshot parameters with RCU on replace\n\nThe gate action can be replaced while the hrtimer callback or dump path is\nwalking the schedule list.\n\nConvert the parameters to an RCU-protected snapshot and swap updates under\ntcf_lock, freeing the previous snapshot via call_rcu(). When REPLACE omits\nthe entry list, preserve the existing schedule so the effective state is\nunchanged.(CVE-2026-23245)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: gro: fix outer network offset\n\nThe udp GRO complete stage assumes that all the packets inserted the RX\nhave the `encapsulation` flag zeroed. Such assumption is not true, as a\nfew H/W NICs can set such flag when H/W offloading the checksum for\nan UDP encapsulated traffic, the tun driver can inject GSO packets with\nUDP encapsulation and the problematic layout can also be created via\na veth based setup.\n\nDue to the above, in the problematic scenarios, udp4_gro_complete() uses\nthe wrong network offset (inner instead of outer) to compute the outer\nUDP header pseudo checksum, leading to csum validation errors later on\nin packet processing.\n\nAddress the issue always clearing the encapsulation flag at GRO completion\ntime. Such flag will be set again as needed for encapsulated packets by\nudp_gro_complete().(CVE-2026-23254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: add proper RCU protection to /proc/net/ptype\n\nYin Fengwei reported an RCU stall in ptype_seq_show() and provided\na patch.\n\nReal issue is that ptype_seq_next() and ptype_seq_show() violate\nRCU rules.\n\nptype_seq_show() runs under rcu_read_lock(), and reads pt-\u0026gt;dev\nto get device name without any barrier.\n\nAt the same time, concurrent writers can remove a packet_type structure\n(which is correctly freed after an RCU grace period) and clear pt-\u0026gt;dev\nwithout an RCU grace period.\n\nDefine ptype_iter_state to carry a dev pointer along seq_net_private:\n\nstruct ptype_iter_state {\n\tstruct seq_net_private\tp;\n\tstruct net_device\t*dev; // added in this patch\n};\n\nWe need to record the device pointer in ptype_get_idx() and\nptype_seq_next() so that ptype_seq_show() is safe against\nconcurrent pt-\u0026gt;dev changes.\n\nWe also need to add full RCU protection in ptype_seq_next().\n(Missing READ_ONCE() when reading list.next values)\n\nMany thanks to Dong Chenchen for providing a repro.(CVE-2026-23255)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocks\n\nAs Paolo said earlier [1]:\n\n\u0026quot;Since the blamed commit below, classify can return TC_ACT_CONSUMED while\nthe current skb being held by the defragmentation engine. As reported by\nGangMin Kim, if such packet is that may cause a UaF when the defrag engine\nlater on tries to tuch again such packet.\u0026quot;\n\nact_ct was never meant to be used in the egress path, however some users\nare attaching it to egress today [2]. Attempting to reach a middle\nground, we noticed that, while most qdiscs are not handling\nTC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, we\naddress the issue by only allowing act_ct to bind to clsact/ingress\nqdiscs and shared blocks. That way it\u0026apos;s still possible to attach act_ct to\negress (albeit only with clsact).\n\n[1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/\n[2] https://lore.kernel.org/netdev/(CVE-2026-23270)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels\n\nIDLETIMER revision 0 rules reuse existing timers by label and always call\nmod_timer() on timer-\u0026gt;timer.\n\nIf the label was created first by revision 1 with XT_IDLETIMER_ALARM,\nthe object uses alarm timer semantics and timer-\u0026gt;timer is never initialized.\nReusing that object from revision 0 causes mod_timer() on an uninitialized\ntimer_list, triggering debugobjects warnings and possible panic when\npanic_on_warn=1.\n\nFix this by rejecting revision 0 rule insertion when an existing timer with\nthe same label is of ALARM type.(CVE-2026-23274)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: add xmit recursion limit to tunnel xmit functions\n\nTunnel xmit functions (iptunnel_xmit, ip6tunnel_xmit) lack their own\nrecursion limit. When a bond device in broadcast mode has GRE tap\ninterfaces as slaves, and those GRE tunnels route back through the\nbond, multicast/broadcast traffic triggers infinite recursion between\nbond_xmit_broadcast() and ip_tunnel_xmit()/ip6_tnl_xmit(), causing\nkernel stack overflow.\n\nThe existing XMIT_RECURSION_LIMIT (8) in the no-qdisc path is not\nsufficient because tunnel recursion involves route lookups and full IP\noutput, consuming much more stack per level. Use a lower limit of 4\n(IP_TUNNEL_RECURSION_LIMIT) to prevent overflow.\n\nAdd recursion detection using dev_xmit_recursion helpers directly in\niptunnel_xmit() and ip6tunnel_xmit() to cover all IPv4/IPv6 tunnel\npaths including UDP encapsulated tunnels (VXLAN, Geneve, etc.).\n\nMove dev_xmit_recursion helpers from net/core/dev.h to public header\ninclude/linux/netdevice.h so they can be used by tunnel code.\n\n BUG: KASAN: stack-out-of-bounds in blake2s.constprop.0+0xe7/0x160\n Write of size 32 at addr ffff88810033fed0 by task kworker/0:1/11\n Workqueue: mld mld_ifc_work\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __build_flow_key.constprop.0 (net/ipv4/route.c:515)\n ip_rt_update_pmtu (net/ipv4/route.c:1073)\n iptunnel_xmit (net/ipv4/ip_tunnel_core.c:84)\n ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847)\n gre_tap_xmit (net/ipv4/ip_gre.c:779)\n dev_hard_start_xmit (net/core/dev.c:3887)\n sch_direct_xmit (net/sched/sch_generic.c:347)\n __dev_queue_xmit (net/core/dev.c:4802)\n bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)\n bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)\n bond_start_xmit (drivers/net/bonding/bond_main.c:5530)\n dev_hard_start_xmit (net/core/dev.c:3887)\n __dev_queue_xmit (net/core/dev.c:4841)\n ip_finish_output2 (net/ipv4/ip_output.c:237)\n ip_output (net/ipv4/ip_output.c:438)\n iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86)\n gre_tap_xmit (net/ipv4/ip_gre.c:779)\n dev_hard_start_xmit (net/core/dev.c:3887)\n sch_direct_xmit (net/sched/sch_generic.c:347)\n __dev_queue_xmit (net/core/dev.c:4802)\n bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)\n bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)\n bond_start_xmit (drivers/net/bonding/bond_main.c:5530)\n dev_hard_start_xmit (net/core/dev.c:3887)\n __dev_queue_xmit (net/core/dev.c:4841)\n ip_finish_output2 (net/ipv4/ip_output.c:237)\n ip_output (net/ipv4/ip_output.c:438)\n iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86)\n ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847)\n gre_tap_xmit (net/ipv4/ip_gre.c:779)\n dev_hard_start_xmit (net/core/dev.c:3887)\n sch_direct_xmit (net/sched/sch_generic.c:347)\n __dev_queue_xmit (net/core/dev.c:4802)\n bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)\n bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)\n bond_start_xmit (drivers/net/bonding/bond_main.c:5530)\n dev_hard_start_xmit (net/core/dev.c:3887)\n __dev_queue_xmit (net/core/dev.c:4841)\n mld_sendpack\n mld_ifc_work\n process_one_work\n worker_thread\n \u0026lt;/TASK\u0026gt;(CVE-2026-23276)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit\n\nteql_master_xmit() calls netdev_start_xmit(skb, slave) to transmit\nthrough slave devices, but does not update skb-\u0026gt;dev to the slave device\nbeforehand.\n\nWhen a gretap tunnel is a TEQL slave, the transmit path reaches\niptunnel_xmit() which saves dev = skb-\u0026gt;dev (still pointing to teql0\nmaster) and later calls iptunnel_xmit_stats(dev, pkt_len). This\nfunction does:\n\n get_cpu_ptr(dev-\u0026gt;tstats)\n\nSince teql_master_setup() does not set dev-\u0026gt;pcpu_stat_type to\nNETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstats\nfor teql0, so dev-\u0026gt;tstats is NULL. get_cpu_ptr(NULL) computes\nNULL + __per_cpu_offset[cpu], resulting in a page fault.\n\n BUG: unable to handle page fault for address: ffff8880e6659018\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 68bc067 P4D 68bc067 PUD 0\n Oops: Oops: 0002 [#1] SMP KASAN PTI\n RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89)\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847)\n __gre_xmit (net/ipv4/ip_gre.c:478)\n gre_tap_xmit (net/ipv4/ip_gre.c:779)\n teql_master_xmit (net/sched/sch_teql.c:319)\n dev_hard_start_xmit (net/core/dev.c:3887)\n sch_direct_xmit (net/sched/sch_generic.c:347)\n __dev_queue_xmit (net/core/dev.c:4802)\n neigh_direct_output (net/core/neighbour.c:1660)\n ip_finish_output2 (net/ipv4/ip_output.c:237)\n __ip_finish_output.part.0 (net/ipv4/ip_output.c:315)\n ip_mc_output (net/ipv4/ip_output.c:369)\n ip_send_skb (net/ipv4/ip_output.c:1508)\n udp_send_skb (net/ipv4/udp.c:1195)\n udp_sendmsg (net/ipv4/udp.c:1485)\n inet_sendmsg (net/ipv4/af_inet.c:859)\n __sys_sendto (net/socket.c:2206)\n\nFix this by setting skb-\u0026gt;dev = slave before calling\nnetdev_start_xmit(), so that tunnel xmit functions see the correct\nslave device with properly allocated tstats.(CVE-2026-23277)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: always walk all pending catchall elements\n\nDuring transaction processing we might have more than one catchall element:\n1 live catchall element and 1 pending element that is coming as part of the\nnew batch.\n\nIf the map holding the catchall elements is also going away, its\nrequired to toggle all catchall elements and not just the first viable\ncandidate.\n\nOtherwise, we get:\n WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404\n RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables]\n [..]\n __nft_set_elem_destroy+0x106/0x380 [nf_tables]\n nf_tables_abort_release+0x348/0x8d0 [nf_tables]\n nf_tables_abort+0xcf2/0x3ac0 [nf_tables]\n nfnetlink_rcv_batch+0x9c9/0x20e0 [..](CVE-2026-23278)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled\n\nWhen booting with the \u0026apos;ipv6.disable=1\u0026apos; parameter, the nd_tbl is never\ninitialized because inet6_init() exits before ndisc_init() is called\nwhich initializes it. If an IPv6 packet is injected into the interface,\nroute_shortcircuit() is called and a NULL pointer dereference happens on\nneigh_lookup().\n\n BUG: kernel NULL pointer dereference, address: 0000000000000380\n Oops: Oops: 0000 [#1] SMP NOPTI\n [...]\n RIP: 0010:neigh_lookup+0x20/0x270\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_xmit+0x638/0x1ef0 [vxlan]\n dev_hard_start_xmit+0x9e/0x2e0\n __dev_queue_xmit+0xbee/0x14e0\n packet_sendmsg+0x116f/0x1930\n __sys_sendto+0x1f5/0x200\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0x12f/0x1590\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFix this by adding an early check on route_shortcircuit() when protocol\nis ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here because\nVXLAN can be built-in even when IPv6 is built as a module.(CVE-2026-23293)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop\n\nWhen a standalone IPv6 nexthop object is created with a loopback device\n(e.g., \u0026quot;ip -6 nexthop add id 100 dev lo\u0026quot;), fib6_nh_init() misclassifies\nit as a reject route. This is because nexthop objects have no destination\nprefix (fc_dst=::), causing fib6_is_reject() to match any loopback\nnexthop. The reject path skips fib_nh_common_init(), leaving\nnhc_pcpu_rth_output unallocated. If an IPv4 route later references this\nnexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and\npanics.\n\nSimplify the check in fib6_nh_init() to only match explicit reject\nroutes (RTF_REJECT) instead of using fib6_is_reject(). The loopback\npromotion heuristic in fib6_is_reject() is handled separately by\nip6_route_info_create_nh(). After this change, the three cases behave\nas follows:\n\n1. Explicit reject route (\u0026quot;ip -6 route add unreachable 2001:db8::/64\u0026quot;):\n RTF_REJECT is set, enters reject path, skips fib_nh_common_init().\n No behavior change.\n\n2. Implicit loopback reject route (\u0026quot;ip -6 route add 2001:db8::/32 dev lo\u0026quot;):\n RTF_REJECT is not set, takes normal path, fib_nh_common_init() is\n called. ip6_route_info_create_nh() still promotes it to reject\n afterward. nhc_pcpu_rth_output is allocated but unused, which is\n harmless.\n\n3. Standalone nexthop object (\u0026quot;ip -6 nexthop add id 100 dev lo\u0026quot;):\n RTF_REJECT is not set, takes normal path, fib_nh_common_init() is\n called. nhc_pcpu_rth_output is properly allocated, fixing the crash\n when IPv4 routes reference this nexthop.(CVE-2026-23300)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: annotate data-races around sk-\u0026gt;sk_{data_ready,write_space}\n\nskmsg (and probably other layers) are changing these pointers\nwhile other cpus might read them concurrently.\n\nAdd corresponding READ_ONCE()/WRITE_ONCE() annotations\nfor UDP, TCP and AF_UNIX.(CVE-2026-23302)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Don\u0026apos;t log plaintext credentials in cifs_set_cifscreds\n\nWhen debug logging is enabled, cifs_set_cifscreds() logs the key\npayload and exposes the plaintext username and password. Remove the\ndebug log to avoid exposing credentials.(CVE-2026-23303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()\n\nl3mdev_master_dev_rcu() can return NULL when the slave device is being\nun-slaved from a VRF. All other callers deal with this, but we lost\nthe fallback to loopback in ip6_rt_pcpu_alloc() -\u0026gt; ip6_rt_get_dev_rcu()\nwith commit 4832c30d5458 (\u0026quot;net: ipv6: put host and anycast routes on\ndevice with address\u0026quot;).\n\n KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]\n RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418)\n Call Trace:\n ip6_pol_route (net/ipv6/route.c:2318)\n fib6_rule_lookup (net/ipv6/fib6_rules.c:115)\n ip6_route_output_flags (net/ipv6/route.c:2607)\n vrf_process_v6_outbound (drivers/net/vrf.c:437)\n\nI was tempted to rework the un-slaving code to clear the flag first\nand insert synchronize_rcu() before we remove the upper. But looks like\nthe explicit fallback to loopback_dev is an established pattern.\nAnd I guess avoiding the synchronize_rcu() is nice, too.(CVE-2026-23304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf/bonding: reject vlan+srcmac xmit_hash_policy change when XDP is loaded\n\nbond_option_mode_set() already rejects mode changes that would make a\nloaded XDP program incompatible via bond_xdp_check(). However,\nbond_option_xmit_hash_policy_set() has no such guard.\n\nFor 802.3ad and balance-xor modes, bond_xdp_check() returns false when\nxmit_hash_policy is vlan+srcmac, because the 802.1q payload is usually\nabsent due to hardware offload. This means a user can:\n\n1. Attach a native XDP program to a bond in 802.3ad/balance-xor mode\n with a compatible xmit_hash_policy (e.g. layer2+3).\n2. Change xmit_hash_policy to vlan+srcmac while XDP remains loaded.\n\nThis leaves bond-\u0026gt;xdp_prog set but bond_xdp_check() now returning false\nfor the same device. When the bond is later destroyed, dev_xdp_uninstall()\ncalls bond_xdp_set(dev, NULL, NULL) to remove the program, which hits\nthe bond_xdp_check() guard and returns -EOPNOTSUPP, triggering:\n\nWARN_ON(dev_xdp_install(dev, mode, bpf_op, NULL, 0, NULL))\n\nFix this by rejecting xmit_hash_policy changes to vlan+srcmac when an\nXDP program is loaded on a bond in 802.3ad or balance-xor mode.\n\ncommit 39a0876d595b (\u0026quot;net, bonding: Disallow vlan+srcmac with XDP\u0026quot;)\nintroduced bond_xdp_check() which returns false for 802.3ad/balance-xor\nmodes when xmit_hash_policy is vlan+srcmac. The check was wired into\nbond_xdp_set() to reject XDP attachment with an incompatible policy, but\nthe symmetric path -- preventing xmit_hash_policy from being changed to an\nincompatible value after XDP is already loaded -- was left unguarded in\nbond_option_xmit_hash_policy_set().\n\nNote:\ncommit 094ee6017ea0 (\u0026quot;bonding: check xdp prog when set bond mode\u0026quot;)\nlater added a similar guard to bond_option_mode_set(), but\nbond_option_xmit_hash_policy_set() remained unprotected.(CVE-2026-23310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: in-kernel: always mark signal+subflow endp as used\n\nSyzkaller managed to find a combination of actions that was generating\nthis warning:\n\n msk-\u0026gt;pm.local_addr_used == 0\n WARNING: net/mptcp/pm_kernel.c:1071 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline], CPU#1: syz.2.17/961\n WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline], CPU#1: syz.2.17/961\n WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210, CPU#1: syz.2.17/961\n Modules linked in:\n CPU: 1 UID: 0 PID: 961 Comm: syz.2.17 Not tainted 6.19.0-08368-gfafda3b4b06b #22 PREEMPT(full)\n Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.17.0-debian-1.17.0-1build1 04/01/2014\n RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline]\n RIP: 0010:mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline]\n RIP: 0010:mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210\n Code: 89 c5 e8 46 30 6f fe e9 21 fd ff ff 49 83 ed 80 e8 38 30 6f fe 4c 89 ef be 03 00 00 00 e8 db 49 df fe eb ac e8 24 30 6f fe 90 \u0026lt;0f\u0026gt; 0b 90 e9 1d ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a\n RSP: 0018:ffffc90001663880 EFLAGS: 00010293\n RAX: ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff\n R10: ffffffff82de18ba R11: 0000000000000000 R12: ffff88800641a640\n R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650\n FS: 00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]\n netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344\n netlink_sendmsg+0x4aa/0x5b0 net/netlink/af_netlink.c:1894\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0xc9/0xf0 net/socket.c:742\n ____sys_sendmsg+0x272/0x3b0 net/socket.c:2592\n ___sys_sendmsg+0x2de/0x320 net/socket.c:2646\n __sys_sendmsg net/socket.c:2678 [inline]\n __do_sys_sendmsg net/socket.c:2683 [inline]\n __se_sys_sendmsg net/socket.c:2681 [inline]\n __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2681\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0x143/0x440 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7f66346f826d\n Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48\n RSP: 002b:00007ffc83d8bdc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\n RAX: ffffffffffffffda RBX: 00007f6634985fa0 RCX: 00007f66346f826d\n RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007\n RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6634985fa8\n R13: 00007f6634985fac R14: 0000000000000000 R15: 0000000000001770\n \u0026lt;/TASK\u0026gt;\n\nThe actions that caused that seem to be:\n\n - Set the MPTCP subflows limit to 0\n - Create an MPTCP endpoint with both the \u0026apos;signal\u0026apos; and \u0026apos;subflow\u0026apos; flags\n - Create a new MPTCP connection from a different address: an ADD_ADDR\n linked to the MPTCP endpoint will be sent (\u0026apos;signal\u0026apos; flag), but no\n subflows is initiated (\u0026apos;subflow\u0026apos; flag)\n - Remove the MPTCP endpoint\n\n---truncated---(CVE-2026-23321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxdp: produce a warning when calculated tailroom is negative\n\nMany ethernet drivers report xdp Rx queue frag size as being the same as\nDMA write size. However, the only user of this field, namely\nbpf_xdp_frags_increase_tail(), clearly expects a truesize.\n\nSuch difference leads to unspecific memory corruption issues under certain\ncircumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when\nrunning xskxceiver\u0026apos;s XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses\nall DMA-writable space in 2 buffers. This would be fine, if only\nrxq-\u0026gt;frag_size was properly set to 4K, but value of 3K results in a\nnegative tailroom, because there is a non-zero page offset.\n\nWe are supposed to return -EINVAL and be done with it in such case, but due\nto tailroom being stored as an unsigned int, it is reported to be somewhere\nnear UINT_MAX, resulting in a tail being grown, even if the requested\noffset is too much (it is around 2K in the abovementioned test). This later\nleads to all kinds of unspecific calltraces.\n\n[ 7340.337579] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6\n[ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4\n[ 7340.338179] in libc.so.6[61c9d,7f4161aaf000+160000]\n[ 7340.339230] in xskxceiver[42b5,400000+69000]\n[ 7340.340300] likely on CPU 6 (core 0, socket 6)\n[ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 \u0026lt;4c\u0026gt; 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe\n[ 7340.340888] likely on CPU 3 (core 0, socket 3)\n[ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff \u0026lt;8b\u0026gt; 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7\n[ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d255010bdffc: 0000 [#1] SMP NOPTI\n[ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy)\n[ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014\n[ 7340.409716] RIP: 0010:lookup_swap_cgroup_id+0x44/0x80\n[ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 \u0026lt;8b\u0026gt; 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89\n[ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202\n[ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010\n[ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff\n[ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0\n[ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0\n[ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500\n[ 7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000\n[ 7340.419489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0\n[ 7340.421237] PKRU: 55555554\n[ 7340.421623] Call Trace:\n[ 7340.421987] \u0026lt;TASK\u0026gt;\n[ 7340.422309] ? softleaf_from_pte+0x77/0xa0\n[ 7340.422855] swap_pte_batch+0xa7/0x290\n[ 7340.423363] zap_nonpresent_ptes.constprop.0.isra.0+0xd1/0x270\n[ 7340.424102] zap_pte_range+0x281/0x580\n[ 7340.424607] zap_pmd_range.isra.0+0xc9/0x240\n[ 7340.425177] unmap_page_range+0x24d/0x420\n[ 7340.425714] unmap_vmas+0xa1/0x180\n[ 7340.426185] exit_mmap+0xe1/0x3b0\n[ 7340.426644] __mmput+0x41/0x150\n[ 7340.427098] exit_mm+0xb1/0x110\n[ 7340.427539] do_exit+0x1b2/0x460\n[ 7340.427992] do_group_exit+0x2d/0xc0\n[ 7340.428477] get_signal+0x79d/0x7e0\n[ 7340.428957] arch_do_signal_or_restart+0x34/0x100\n[ 7340.429571] exit_to_user_mode_loop+0x8e/0x4c0\n[ 7340.430159] do_syscall_64+0x188/\n---truncated---(CVE-2026-23343)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: split gc into unlink and reclaim phase\n\nYiming Qian reports Use-after-free in the pipapo set type:\n Under a large number of expired elements, commit-time GC can run for a very\n long time in a non-preemptible context, triggering soft lockup warnings and\n RCU stall reports (local denial of service).\n\nWe must split GC in an unlink and a reclaim phase.\n\nWe cannot queue elements for freeing until pointers have been swapped.\nExpired elements are still exposed to both the packet path and userspace\ndumpers via the live copy of the data structure.\n\ncall_rcu() does not protect us: dump operations or element lookups starting\nafter call_rcu has fired can still observe the free\u0026apos;d element, unless the\ncommit phase has made enough progress to swap the clone and live pointers\nbefore any new reader has picked up the old version.\n\nThis a similar approach as done recently for the rbtree backend in commit\n35f83a75529a (\u0026quot;netfilter: nft_set_rbtree: don\u0026apos;t gc elements on insert\u0026quot;).(CVE-2026-23351)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: fix locking for bcm_op runtime updates\n\nCommit c2aba69d0c36 (\u0026quot;can: bcm: add locking for bcm_op runtime updates\u0026quot;)\nadded a locking for some variables that can be modified at runtime when\nupdating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup().\n\nUsually the RX_SETUP only handles and filters incoming traffic with one\nexception: When the RX_RTR_FRAME flag is set a predefined CAN frame is\nsent when a specific RTR frame is received. Therefore the rx bcm_op uses\nbcm_can_tx() which uses the bcm_tx_lock that was only initialized in\nbcm_tx_setup(). Add the missing spin_lock_init() when allocating the\nbcm_op in bcm_rx_setup() to handle the RTR case properly.(CVE-2026-23362)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: kalmia: validate USB endpoints\n\nThe kalmia driver should validate that the device it is probing has the\nproper number and types of USB endpoints it is expecting before it binds\nto it. If a malicious device were to not have the same urbs the driver\nwill crash later on when it blindly accesses these endpoints.(CVE-2026-23365)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: register phy led_triggers during probe to avoid AB-BA deadlock\n\nThere is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and\nLED_TRIGGER_PHY are enabled:\n\n[ 1362.049207] [\u0026lt;8054e4b8\u0026gt;] led_trigger_register+0x5c/0x1fc \u0026lt;-- Trying to get lock \u0026quot;triggers_list_lock\u0026quot; via down_write(\u0026amp;triggers_list_lock);\n[ 1362.054536] [\u0026lt;80662830\u0026gt;] phy_led_triggers_register+0xd0/0x234\n[ 1362.060329] [\u0026lt;8065e200\u0026gt;] phy_attach_direct+0x33c/0x40c\n[ 1362.065489] [\u0026lt;80651fc4\u0026gt;] phylink_fwnode_phy_connect+0x15c/0x23c\n[ 1362.071480] [\u0026lt;8066ee18\u0026gt;] mtk_open+0x7c/0xba0\n[ 1362.075849] [\u0026lt;806d714c\u0026gt;] __dev_open+0x280/0x2b0\n[ 1362.080384] [\u0026lt;806d7668\u0026gt;] __dev_change_flags+0x244/0x24c\n[ 1362.085598] [\u0026lt;806d7698\u0026gt;] dev_change_flags+0x28/0x78\n[ 1362.090528] [\u0026lt;807150e4\u0026gt;] dev_ioctl+0x4c0/0x654 \u0026lt;-- Hold lock \u0026quot;rtnl_mutex\u0026quot; by calling rtnl_lock();\n[ 1362.094985] [\u0026lt;80694360\u0026gt;] sock_ioctl+0x2f4/0x4e0\n[ 1362.099567] [\u0026lt;802e9c4c\u0026gt;] sys_ioctl+0x32c/0xd8c\n[ 1362.104022] [\u0026lt;80014504\u0026gt;] syscall_common+0x34/0x58\n\nHere LED_TRIGGER_PHY is registering LED triggers during phy_attach\nwhile holding RTNL and then taking triggers_list_lock.\n\n[ 1362.191101] [\u0026lt;806c2640\u0026gt;] register_netdevice_notifier+0x60/0x168 \u0026lt;-- Trying to get lock \u0026quot;rtnl_mutex\u0026quot; via rtnl_lock();\n[ 1362.197073] [\u0026lt;805504ac\u0026gt;] netdev_trig_activate+0x194/0x1e4\n[ 1362.202490] [\u0026lt;8054e28c\u0026gt;] led_trigger_set+0x1d4/0x360 \u0026lt;-- Hold lock \u0026quot;triggers_list_lock\u0026quot; by down_read(\u0026amp;triggers_list_lock);\n[ 1362.207511] [\u0026lt;8054eb38\u0026gt;] led_trigger_write+0xd8/0x14c\n[ 1362.212566] [\u0026lt;80381d98\u0026gt;] sysfs_kf_bin_write+0x80/0xbc\n[ 1362.217688] [\u0026lt;8037fcd8\u0026gt;] kernfs_fop_write_iter+0x17c/0x28c\n[ 1362.223174] [\u0026lt;802cbd70\u0026gt;] vfs_write+0x21c/0x3c4\n[ 1362.227712] [\u0026lt;802cc0c4\u0026gt;] ksys_write+0x78/0x12c\n[ 1362.232164] [\u0026lt;80014504\u0026gt;] syscall_common+0x34/0x58\n\nHere LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takes\ntriggers_list_lock and then RTNL. A classical AB-BA deadlock.\n\nphy_led_triggers_registers() does not require the RTNL, it does not\nmake any calls into the network stack which require protection. There\nis also no requirement the PHY has been attached to a MAC, the\ntriggers only make use of phydev state. This allows the call to\nphy_led_triggers_registers() to be placed elsewhere. PHY probe() and\nrelease() don\u0026apos;t hold RTNL, so solving the AB-BA deadlock.(CVE-2026-23368)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting\n\nRunning stress-ng --schedpolicy 0 on an RT kernel on a big machine\nmight lead to the following WARNINGs (edited).\n\n sched: DL de-boosted task PID 22725: REPLENISH flag missing\n\n WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8\n ... (running_bw underflow)\n Call trace:\n dequeue_task_dl+0x15c/0x1f8 (P)\n dequeue_task+0x80/0x168\n deactivate_task+0x24/0x50\n push_dl_task+0x264/0x2e0\n dl_task_timer+0x1b0/0x228\n __hrtimer_run_queues+0x188/0x378\n hrtimer_interrupt+0xfc/0x260\n ...\n\nThe problem is that when a SCHED_DEADLINE task (lock holder) is\nchanged to a lower priority class via sched_setscheduler(), it may\nfail to properly inherit the parameters of potential DEADLINE donors\nif it didn\u0026apos;t already inherit them in the past (shorter deadline than\ndonor\u0026apos;s at that time). This might lead to bandwidth accounting\ncorruption, as enqueue_task_dl() won\u0026apos;t recognize the lock holder as\nboosted.\n\nThe scenario occurs when:\n1. A DEADLINE task (donor) blocks on a PI mutex held by another\n DEADLINE task (holder), but the holder doesn\u0026apos;t inherit parameters\n (e.g., it already has a shorter deadline)\n2. sched_setscheduler() changes the holder from DEADLINE to a lower\n class while still holding the mutex\n3. The holder should now inherit DEADLINE parameters from the donor\n and be enqueued with ENQUEUE_REPLENISH, but this doesn\u0026apos;t happen\n\nFix the issue by introducing __setscheduler_dl_pi(), which detects when\na DEADLINE (proper or boosted) task gets setscheduled to a lower\npriority class. In case, the function makes the task inherit DEADLINE\nparameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag to\nensure proper bandwidth accounting during the next enqueue operation.(CVE-2026-23371)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: thp: deny THP for files on anonymous inodes\n\nfile_thp_enabled() incorrectly allows THP for files on anonymous inodes\n(e.g. guest_memfd and secretmem). These files are created via\nalloc_file_pseudo(), which does not call get_write_access() and leaves\ninode-\u0026gt;i_writecount at 0. Combined with S_ISREG(inode-\u0026gt;i_mode) being\ntrue, they appear as read-only regular files when\nCONFIG_READ_ONLY_THP_FOR_FS is enabled, making them eligible for THP\ncollapse.\n\nAnonymous inodes can never pass the inode_is_open_for_write() check\nsince their i_writecount is never incremented through the normal VFS\nopen path. The right thing to do is to exclude them from THP eligibility\naltogether, since CONFIG_READ_ONLY_THP_FOR_FS was designed for real\nfilesystem files (e.g. shared libraries), not for pseudo-filesystem\ninodes.\n\nFor guest_memfd, this allows khugepaged and MADV_COLLAPSE to create\nlarge folios in the page cache via the collapse path, but the\nguest_memfd fault handler does not support large folios. This triggers\nWARN_ON_ONCE(folio_test_large(folio)) in kvm_gmem_fault_user_mapping().\n\nFor secretmem, collapse_file() tries to copy page contents through the\ndirect map, but secretmem pages are removed from the direct map. This\ncan result in a kernel crash:\n\n BUG: unable to handle page fault for address: ffff88810284d000\n RIP: 0010:memcpy_orig+0x16/0x130\n Call Trace:\n collapse_file\n hpage_collapse_scan_file\n madvise_collapse\n\nSecretmem is not affected by the crash on upstream as the memory failure\nrecovery handles the failed copy gracefully, but it still triggers\nconfusing false memory failure reports:\n\n Memory failure: 0x106d96f: recovery action for clean unevictable\n LRU page: Recovered\n\nCheck IS_ANON_FILE(inode) in file_thp_enabled() to deny THP for all\nanonymous inode files.(CVE-2026-23375)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: fix nd_tbl NULL dereference when IPv6 is disabled\n\nWhen booting with the \u0026apos;ipv6.disable=1\u0026apos; parameter, the nd_tbl is never\ninitialized because inet6_init() exits before ndisc_init() is called\nwhich initializes it. Then, if neigh_suppress is enabled and an ICMPv6\nNeighbor Discovery packet reaches the bridge, br_do_suppress_nd() will\ndereference ipv6_stub-\u0026gt;nd_tbl which is NULL, passing it to\nneigh_lookup(). This causes a kernel NULL pointer dereference.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000268\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n [...]\n RIP: 0010:neigh_lookup+0x16/0xe0\n [...]\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n ? neigh_lookup+0x16/0xe0\n br_do_suppress_nd+0x160/0x290 [bridge]\n br_handle_frame_finish+0x500/0x620 [bridge]\n br_handle_frame+0x353/0x440 [bridge]\n __netif_receive_skb_core.constprop.0+0x298/0x1110\n __netif_receive_skb_one_core+0x3d/0xa0\n process_backlog+0xa0/0x140\n __napi_poll+0x2c/0x170\n net_rx_action+0x2c4/0x3a0\n handle_softirqs+0xd0/0x270\n do_softirq+0x3f/0x60\n\nFix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in\nthe callers. This is in essence disabling NS/NA suppression when IPv6 is\ndisabled.(CVE-2026-23381)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_CT: drop pending enqueued packets on template removal\n\nTemplates refer to objects that can go away while packets are sitting in\nnfqueue refer to:\n\n- helper, this can be an issue on module removal.\n- timeout policy, nfnetlink_cttimeout might remove it.\n\nThe use of templates with zone and event cache filter are safe, since\nthis just copies values.\n\nFlush these enqueued packets in case the template rule gets removed.(CVE-2026-23391)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: release flowtable after rcu grace period on error\n\nCall synchronize_rcu() after unregistering the hooks from error path,\nsince a hook that already refers to this flowtable can be already\nregistered, exposing this flowtable to packet path and nfnetlink_hook\ncontrol plane.\n\nThis error path is rare, it should only happen by reaching the maximum\nnumber hooks or by failing to set up to hardware offload, just call\nsynchronize_rcu().\n\nThere is a check for already used device hooks by different flowtable\nthat could result in EEXIST at this late stage. The hook parser can be\nupdated to perform this check earlier to this error path really becomes\nrarely exercised.\n\nUncovered by KASAN reported as use-after-free from nfnetlink_hook path\nwhen dumping hooks.(CVE-2026-23392)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: cfm: Fix race condition in peer_mep deletion\n\nWhen a peer MEP is being deleted, cancel_delayed_work_sync() is called\non ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs in\nsoftirq context under rcu_read_lock (without RTNL) and can re-schedule\nccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync()\nreturning and kfree_rcu() being called.\n\nThe following is a simple race scenario:\n\n cpu0 cpu1\n\nmep_delete_implementation()\n cancel_delayed_work_sync(ccm_rx_dwork);\n br_cfm_frame_rx()\n // peer_mep still in hlist\n if (peer_mep-\u0026gt;ccm_defect)\n ccm_rx_timer_start()\n queue_delayed_work(ccm_rx_dwork)\n hlist_del_rcu(\u0026amp;peer_mep-\u0026gt;head);\n kfree_rcu(peer_mep, rcu);\n ccm_rx_work_expired()\n // on freed peer_mep\n\nTo prevent this, cancel_delayed_work_sync() is replaced with\ndisable_delayed_work_sync() in both peer MEP deletion paths, so\nthat subsequent queue_delayed_work() calls from br_cfm_frame_rx()\nare silently rejected.\n\nThe cc_peer_disable() helper retains cancel_delayed_work_sync()\nbecause it is also used for the CC enable/disable toggle path where\nthe work must remain re-schedulable.(CVE-2026-23393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Give up GC if MSG_PEEK intervened.\n\nIgor Ushakov reported that GC purged the receive queue of\nan alive socket due to a race with MSG_PEEK with a nice repro.\n\nThis is the exact same issue previously fixed by commit\ncbcf01128d0a (\u0026quot;af_unix: fix garbage collect vs MSG_PEEK\u0026quot;).\n\nAfter GC was replaced with the current algorithm, the cited\ncommit removed the locking dance in unix_peek_fds() and\nreintroduced the same issue.\n\nThe problem is that MSG_PEEK bumps a file refcount without\ninteracting with GC.\n\nConsider an SCC containing sk-A and sk-B, where sk-A is\nclose()d but can be recv()ed via sk-B.\n\nThe bad thing happens if sk-A is recv()ed with MSG_PEEK from\nsk-B and sk-B is close()d while GC is checking unix_vertex_dead()\nfor sk-A and sk-B.\n\n GC thread User thread\n --------- -----------\n unix_vertex_dead(sk-A)\n -\u0026gt; true \u0026lt;------.\n \\\n `------ recv(sk-B, MSG_PEEK)\n invalidate !! -\u0026gt; sk-A\u0026apos;s file refcount : 1 -\u0026gt; 2\n\n close(sk-B)\n -\u0026gt; sk-B\u0026apos;s file refcount : 2 -\u0026gt; 1\n unix_vertex_dead(sk-B)\n -\u0026gt; true\n\nInitially, sk-A\u0026apos;s file refcount is 1 by the inflight fd in sk-B\nrecvq. GC thinks sk-A is dead because the file refcount is the\nsame as the number of its inflight fds.\n\nHowever, sk-A\u0026apos;s file refcount is bumped silently by MSG_PEEK,\nwhich invalidates the previous evaluation.\n\nAt this moment, sk-B\u0026apos;s file refcount is 2; one by the open fd,\nand one by the inflight fd in sk-A. The subsequent close()\nreleases one refcount by the former.\n\nFinally, GC incorrectly concludes that both sk-A and sk-B are dead.\n\nOne option is to restore the locking dance in unix_peek_fds(),\nbut we can resolve this more elegantly thanks to the new algorithm.\n\nThe point is that the issue does not occur without the subsequent\nclose() and we actually do not need to synchronise MSG_PEEK with\nthe dead SCC detection.\n\nWhen the issue occurs, close() and GC touch the same file refcount.\nIf GC sees the refcount being decremented by close(), it can just\ngive up garbage-collecting the SCC.\n\nTherefore, we only need to signal the race during MSG_PEEK with\na proper memory barrier to make it visible to the GC.\n\nLet\u0026apos;s use seqcount_t to notify GC when MSG_PEEK occurs and let\nit defer the SCC to the next run.\n\nThis way no locking is needed on the MSG_PEEK side, and we can\navoid imposing a penalty on every MSG_PEEK unnecessarily.\n\nNote that we can retry within unix_scc_dead() if MSG_PEEK is\ndetected, but we do not do so to avoid hung task splat from\nabusive MSG_PEEK calls.(CVE-2026-23394)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ\n\nCurrently the code attempts to accept requests regardless of the\ncommand identifier which may cause multiple requests to be marked\nas pending (FLAG_DEFER_SETUP) which can cause more than\nL2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer\ncausing an overflow.\n\nThe spec is quite clear that the same identifier shall not be used on\nsubsequent requests:\n\n\u0026apos;Within each signaling channel a different Identifier shall be used\nfor each successive request or indication.\u0026apos;\nhttps://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d\n\nSo this attempts to check if there are any channels pending with the\nsame identifier and rejects if any are found.(CVE-2026-23395)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfnetlink_osf: validate individual option lengths in fingerprints\n\nnfnl_osf_add_callback() validates opt_num bounds and string\nNUL-termination but does not check individual option length fields.\nA zero-length option causes nf_osf_match_one() to enter the option\nmatching loop even when foptsize sums to zero, which matches packets\nwith no TCP options where ctx-\u0026gt;optp is NULL:\n\n Oops: general protection fault\n KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98)\n Call Trace:\n nf_osf_match (net/netfilter/nfnetlink_osf.c:227)\n xt_osf_match_packet (net/netfilter/xt_osf.c:32)\n ipt_do_table (net/ipv4/netfilter/ip_tables.c:293)\n nf_hook_slow (net/netfilter/core.c:623)\n ip_local_deliver (net/ipv4/ip_input.c:262)\n ip_rcv (net/ipv4/ip_input.c:573)\n\nAdditionally, an MSS option (kind=2) with length \u0026lt; 4 causes\nout-of-bounds reads when nf_osf_match_one() unconditionally accesses\noptp[2] and optp[3] for MSS value extraction. While RFC 9293\nsection 3.2 specifies that the MSS option is always exactly 4\nbytes (Kind=2, Length=4), the check uses \u0026quot;\u0026lt; 4\u0026quot; rather than\n\u0026quot;!= 4\u0026quot; because lengths greater than 4 do not cause memory\nsafety issues -- the buffer is guaranteed to be at least\nfoptsize bytes by the ctx-\u0026gt;optsize == foptsize check.\n\nReject fingerprints where any option has zero length, or where an MSS\noption has length less than 4, at add time rather than trusting these\nvalues in the packet matching hot path.(CVE-2026-23397)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnf_tables: nft_dynset: fix possible stateful expression memleak in error path\n\nIf cloning the second stateful expression in the element via GFP_ATOMIC\nfails, then the first stateful expression remains in place without being\nreleased.\n\n \u00a0 unreferenced object (percpu) 0x607b97e9cab8 (size 16):\n \u00a0 \u00a0 comm \u0026quot;softirq\u0026quot;, pid 0, jiffies 4294931867\n \u00a0 \u00a0 hex dump (first 16 bytes on cpu 3):\n \u00a0 \u00a0 \u00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u00a0 \u00a0 backtrace (crc 0):\n \u00a0 \u00a0 \u00a0 pcpu_alloc_noprof+0x453/0xd80\n \u00a0 \u00a0 \u00a0 nft_counter_clone+0x9c/0x190 [nf_tables]\n \u00a0 \u00a0 \u00a0 nft_expr_clone+0x8f/0x1b0 [nf_tables]\n \u00a0 \u00a0 \u00a0 nft_dynset_new+0x2cb/0x5f0 [nf_tables]\n \u00a0 \u00a0 \u00a0 nft_rhash_update+0x236/0x11c0 [nf_tables]\n \u00a0 \u00a0 \u00a0 nft_dynset_eval+0x11f/0x670 [nf_tables]\n \u00a0 \u00a0 \u00a0 nft_do_chain+0x253/0x1700 [nf_tables]\n \u00a0 \u00a0 \u00a0 nft_do_chain_ipv4+0x18d/0x270 [nf_tables]\n \u00a0 \u00a0 \u00a0 nf_hook_slow+0xaa/0x1e0\n \u00a0 \u00a0 \u00a0 ip_local_deliver+0x209/0x330(CVE-2026-23399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE\n\nWhen installing an emulated MMIO SPTE, do so *after* dropping/zapping the\nexisting SPTE (if it\u0026apos;s shadow-present). While commit a54aa15c6bda3 was\nright about it being impossible to convert a shadow-present SPTE to an\nMMIO SPTE due to a _guest_ write, it failed to account for writes to guest\nmemory that are outside the scope of KVM.\n\nE.g. if host userspace modifies a shadowed gPTE to switch from a memslot\nto emulted MMIO and then the guest hits a relevant page fault, KVM will\ninstall the MMIO SPTE without first zapping the shadow-present SPTE.\n\n ------------[ cut here ]------------\n is_shadow_present_pte(*sptep)\n WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n mmu_set_spte+0x237/0x440 [kvm]\n ept_page_fault+0x535/0x7f0 [kvm]\n kvm_mmu_do_page_fault+0xee/0x1f0 [kvm]\n kvm_mmu_page_fault+0x8d/0x620 [kvm]\n vmx_handle_exit+0x18c/0x5a0 [kvm_intel]\n kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm]\n kvm_vcpu_ioctl+0x2d5/0x980 [kvm]\n __x64_sys_ioctl+0x8a/0xd0\n do_syscall_64+0xb5/0x730\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x47fa3f\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---(CVE-2026-23401)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix memory leak in verify_header\n\nThe function sets `*ns = NULL` on every call, leaking the namespace\nstring allocated in previous iterations when multiple profiles are\nunpacked. This also breaks namespace consistency checking since *ns\nis always NULL when the comparison is made.\n\nRemove the incorrect assignment.\nThe caller (aa_unpack) initializes *ns to NULL once before the loop,\nwhich is sufficient.(CVE-2026-23403)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: replace recursive profile removal with iterative approach\n\nThe profile removal code uses recursion when removing nested profiles,\nwhich can lead to kernel stack exhaustion and system crashes.\n\nReproducer:\n $ pf=\u0026apos;a\u0026apos;; for ((i=0; i\u0026lt;1024; i++)); do\n echo -e \u0026quot;profile $pf { \\n }\u0026quot; | apparmor_parser -K -a;\n pf=\u0026quot;$pf//x\u0026quot;;\n done\n $ echo -n a \u0026gt; /sys/kernel/security/apparmor/.remove\n\nReplace the recursive __aa_profile_list_release() approach with an\niterative approach in __remove_profile(). The function repeatedly\nfinds and removes leaf profiles until the entire subtree is removed,\nmaintaining the same removal semantic without recursion.(CVE-2026-23404)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix: limit the number of levels of policy namespaces\n\nCurrently the number of policy namespaces is not bounded relying on\nthe user namespace limit. However policy namespaces aren\u0026apos;t strictly\ntied to user namespaces and it is possible to create them and nest\nthem arbitrarily deep which can be used to exhaust system resource.\n\nHard cap policy namespaces to the same depth as user namespaces.(CVE-2026-23405)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: Fix double free of ns_name in aa_replace_profiles()\n\nif ns_name is NULL after\n1071 error = aa_unpack(udata, \u0026amp;lh, \u0026amp;ns_name);\n\nand if ent-\u0026gt;ns_name contains an ns_name in\n1089 } else if (ent-\u0026gt;ns_name) {\n\nthen ns_name is assigned the ent-\u0026gt;ns_name\n1095 ns_name = ent-\u0026gt;ns_name;\n\nhowever ent-\u0026gt;ns_name is freed at\n1262 aa_load_ent_free(ent);\n\nand then again when freeing ns_name at\n1270 kfree(ns_name);\n\nFix this by NULLing out ent-\u0026gt;ns_name after it is transferred to ns_name\n\n\u0026quot;)(CVE-2026-23408)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix differential encoding verification\n\nDifferential encoding allows loops to be created if it is abused. To\nprevent this the unpack should verify that a diff-encode chain\nterminates.\n\nUnfortunately the differential encode verification had two bugs.\n\n1. it conflated states that had gone through check and already been\n marked, with states that were currently being checked and marked.\n This means that loops in the current chain being verified are treated\n as a chain that has already been verified.\n\n2. the order bailout on already checked states compared current chain\n check iterators j,k instead of using the outer loop iterator i.\n Meaning a step backwards in states in the current chain verification\n was being mistaken for moving to an already verified state.\n\nMove to a double mark scheme where already verified states get a\ndifferent mark, than the current chain being kept. This enables us\nto also drop the backwards verification check that was the cause of\nthe second error as any already verified state is already marked.(CVE-2026-23409)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix race on rawdata dereference\n\nThere is a race condition that leads to a use-after-free situation:\nbecause the rawdata inodes are not refcounted, an attacker can start\nopen()ing one of the rawdata files, and at the same time remove the\nlast reference to this rawdata (by removing the corresponding profile,\nfor example), which frees its struct aa_loaddata; as a result, when\nseq_rawdata_open() is reached, i_private is a dangling pointer and\nfreed memory is accessed.\n\nThe rawdata inodes weren\u0026apos;t refcounted to avoid a circular refcount and\nwere supposed to be held by the profile rawdata reference. However\nduring profile removal there is a window where the vfs and profile\ndestruction race, resulting in the use after free.\n\nFix this by moving to a double refcount scheme. Where the profile\nrefcount on rawdata is used to break the circular dependency. Allowing\nfor freeing of the rawdata once all inode references to the rawdata\nare put.(CVE-2026-23410)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix race between freeing data and fs accessing it\n\nAppArmor was putting the reference to i_private data on its end after\nremoving the original entry from the file system. However the inode\ncan aand does live beyond that point and it is possible that some of\nthe fs call back functions will be invoked after the reference has\nbeen put, which results in a race between freeing the data and\naccessing it through the fs.\n\nWhile the rawdata/loaddata is the most likely candidate to fail the\nrace, as it has the fewest references. If properly crafted it might be\npossible to trigger a race for the other types stored in i_private.\n\nFix this by moving the put of i_private referenced data to the correct\nplace which is during inode eviction.(CVE-2026-23411)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclsact: Fix use-after-free in init/destroy rollback asymmetry\n\nFix a use-after-free in the clsact qdisc upon init/destroy rollback asymmetry.\nThe latter is achieved by first fully initializing a clsact instance, and\nthen in a second step having a replacement failure for the new clsact qdisc\ninstance. clsact_init() initializes ingress first and then takes care of the\negress part. This can fail midway, for example, via tcf_block_get_ext(). Upon\nfailure, the kernel will trigger the clsact_destroy() callback.\n\nCommit 1cb6f0bae504 (\u0026quot;bpf: Fix too early release of tcx_entry\u0026quot;) details the\nway how the transition is happening. If tcf_block_get_ext on the q-\u0026gt;ingress_block\nends up failing, we took the tcx_miniq_inc reference count on the ingress\nside, but not yet on the egress side. clsact_destroy() tests whether the\n{ingress,egress}_entry was non-NULL. However, even in midway failure on the\nreplacement, both are in fact non-NULL with a valid egress_entry from the\nprevious clsact instance.\n\nWhat we really need to test for is whether the qdisc instance-specific ingress\nor egress side previously got initialized. This adds a small helper for checking\nthe miniq initialization called mini_qdisc_pair_inited, and utilizes that upon\nclsact_destroy() in order to fix the use-after-free scenario. Convert the\ningress_destroy() side as well so both are consistent to each other.(CVE-2026-23413)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntls: Purge async_hold in tls_decrypt_async_wait()\n\nThe async_hold queue pins encrypted input skbs while\nthe AEAD engine references their scatterlist data. Once\ntls_decrypt_async_wait() returns, every AEAD operation\nhas completed and the engine no longer references those\nskbs, so they can be freed unconditionally.\n\nA subsequent patch adds batch async decryption to\ntls_sw_read_sock(), introducing a new call site that\nmust drain pending AEAD operations and release held\nskbs. Move __skb_queue_purge(\u0026amp;ctx-\u0026gt;async_hold) into\ntls_decrypt_async_wait() so the purge is centralized\nand every caller -- recvmsg\u0026apos;s drain path, the -EBUSY\nfallback in tls_do_decryption(), and the new read_sock\nbatch path -- releases held skbs on synchronization\nwithout each site managing the purge independently.\n\nThis fixes a leak when tls_strp_msg_hold() fails part-way through,\nafter having added some cloned skbs to the async_hold\nqueue. tls_decrypt_sg() will then call tls_decrypt_async_wait() to\nprocess all pending decrypts, and drop back to synchronous mode, but\ntls_sw_recvmsg() only flushes the async_hold queue when one record has\nbeen processed in \u0026quot;fully-async\u0026quot; mode, which may not be the case here.\n\n[(CVE-2026-23414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen/privcmd: restrict usage in unprivileged domU\n\nThe Xen privcmd driver allows to issue arbitrary hypercalls from\nuser space processes. This is normally no problem, as access is\nusually limited to root and the hypervisor will deny any hypercalls\naffecting other domains.\n\nIn case the guest is booted using secure boot, however, the privcmd\ndriver would be enabling a root user process to modify e.g. kernel\nmemory contents, thus breaking the secure boot feature.\n\nThe only known case where an unprivileged domU is really needing to\nuse the privcmd driver is the case when it is acting as the device\nmodel for another guest. In this case all hypercalls issued via the\nprivcmd driver will target that other guest.\n\nFortunately the privcmd driver can already be locked down to allow\nonly hypercalls targeting a specific domain, but this mode can be\nactivated from user land only today.\n\nThe target domain can be obtained from Xenstore, so when not running\nin dom0 restrict the privcmd driver to that target domain from the\nbeginning, resolving the potential problem of breaking secure boot.\n\nThis is XSA-482\n\n---\nV2:\n- defer reading from Xenstore if Xenstore isn\u0026apos;t ready yet (Jan Beulich)\n- wait in open() if target domain isn\u0026apos;t known yet\n- issue message in case no target domain found (Jan Beulich)(CVE-2026-31788)",
"id": "OESA-2026-1863",
"modified": "2026-08-06T11:10:52Z",
"published": "2026-04-11T11:10:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68315"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68727"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23096"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23171"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23231"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23240"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23245"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23254"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23255"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23270"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23274"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23276"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23277"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23278"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23293"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23300"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23302"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23303"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23321"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23343"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23351"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23362"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23365"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23368"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23371"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23375"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23381"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23391"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23392"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23394"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23395"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23397"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23399"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23401"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23403"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23404"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23405"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23408"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23409"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23410"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23411"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23413"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23414"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31788"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-68315",
"CVE-2025-68727",
"CVE-2025-71089",
"CVE-2026-23096",
"CVE-2026-23171",
"CVE-2026-23231",
"CVE-2026-23240",
"CVE-2026-23245",
"CVE-2026-23254",
"CVE-2026-23255",
"CVE-2026-23270",
"CVE-2026-23274",
"CVE-2026-23276",
"CVE-2026-23277",
"CVE-2026-23278",
"CVE-2026-23293",
"CVE-2026-23300",
"CVE-2026-23302",
"CVE-2026-23303",
"CVE-2026-23304",
"CVE-2026-23310",
"CVE-2026-23321",
"CVE-2026-23343",
"CVE-2026-23351",
"CVE-2026-23362",
"CVE-2026-23365",
"CVE-2026-23368",
"CVE-2026-23371",
"CVE-2026-23375",
"CVE-2026-23381",
"CVE-2026-23391",
"CVE-2026-23392",
"CVE-2026-23393",
"CVE-2026-23394",
"CVE-2026-23395",
"CVE-2026-23397",
"CVE-2026-23399",
"CVE-2026-23401",
"CVE-2026-23403",
"CVE-2026-23404",
"CVE-2026-23405",
"CVE-2026-23408",
"CVE-2026-23409",
"CVE-2026-23410",
"CVE-2026-23411",
"CVE-2026-23413",
"CVE-2026-23414",
"CVE-2026-31788"
]
}
OESA-2026-2176 (CVE-2025-27558)
Vulnerability from osv_openeuler – Published: 2026-05-03 11:11 – Updated: 2026-08-06 11:11 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
IEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.(CVE-2025-27558)
In the Linux kernel, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)
In the Linux kernel, the following vulnerability has been resolved:
uacce: fix cdev handling in the cleanup path
When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove.(CVE-2026-23096)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ife: Fix metalist update behavior
Whenever an ife action replace changes the metalist, instead of replacing the old data on the metalist, the current ife code is appending the new metadata. Aside from being innapropriate behavior, this may lead to an unbounded addition of metadata to the metalist which might cause an out of bounds error when running the encode op:
[ 138.423369][ C1] ================================================================== [ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ife_out_out_bou/255 [ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full) [ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 138.425800][ C1] Call Trace: [ 138.425804][ C1] <IRQ> [ 138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122) [ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 138.425839][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425844][ C1] ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1)) [ 138.425853][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425859][ C1] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597) [ 138.425868][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425878][ C1] kasan_check_range (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1)) [ 138.425884][ C1] __asan_memset (mm/kasan/shadow.c:84 (discriminator 2)) [ 138.425889][ C1] ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425893][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:171) [ 138.425898][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425903][ C1] ife_encode_meta_u16 (net/sched/act_ife.c:57) [ 138.425910][ C1] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114) [ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3)) [ 138.425921][ C1] ? __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45) [ 138.425927][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425931][ C1] tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879)
To solve this issue, fix the replace behavior by adding the metalist to the ife rcu data structure.(CVE-2026-23378)
In the Linux kernel, the following vulnerability has been resolved:
icmp: fix NULL pointer dereference in icmp_tag_validation()
icmp_tag_validation() unconditionally dereferences the result of rcu_dereference(inet_protos[proto]) without checking for NULL. The inet_protos[] array is sparse -- only about 15 of 256 protocol numbers have registered handlers. When ip_no_pmtu_disc is set to 3 (hardened PMTU mode) and the kernel receives an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number, the NULL dereference causes a kernel panic in softirq context.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: <IRQ> icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) </IRQ>
Add a NULL check before accessing icmp_strict_tag_validation. If the protocol has no registered handler, return false since it cannot perform strict tag validation.(CVE-2026-23398)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix side-effect bug in match_char() macro usage
The match_char() macro evaluates its character parameter multiple times when traversing differential encoding chains. When invoked with *str++, the string pointer advances on each iteration of the inner do-while loop, causing the DFA to check different characters at each iteration and therefore skip input characters. This results in out-of-bounds reads when the pointer advances past the input buffer boundary.
[ 94.984676] ================================================================== [ 94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760 [ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976
[ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 94.986329] Call Trace: [ 94.986341] <TASK> [ 94.986347] dump_stack_lvl+0x5e/0x80 [ 94.986374] print_report+0xc8/0x270 [ 94.986384] ? aa_dfa_match+0x5ae/0x760 [ 94.986388] kasan_report+0x118/0x150 [ 94.986401] ? aa_dfa_match+0x5ae/0x760 [ 94.986405] aa_dfa_match+0x5ae/0x760 [ 94.986408] __aa_path_perm+0x131/0x400 [ 94.986418] aa_path_perm+0x219/0x2f0 [ 94.986424] apparmor_file_open+0x345/0x570 [ 94.986431] security_file_open+0x5c/0x140 [ 94.986442] do_dentry_open+0x2f6/0x1120 [ 94.986450] vfs_open+0x38/0x2b0 [ 94.986453] ? may_open+0x1e2/0x2b0 [ 94.986466] path_openat+0x231b/0x2b30 [ 94.986469] ? __x64_sys_openat+0xf8/0x130 [ 94.986477] do_file_open+0x19d/0x360 [ 94.986487] do_sys_openat2+0x98/0x100 [ 94.986491] __x64_sys_openat+0xf8/0x130 [ 94.986499] do_syscall_64+0x8e/0x660 [ 94.986515] ? count_memcg_events+0x15f/0x3c0 [ 94.986526] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986540] ? handle_mm_fault+0x1639/0x1ef0 [ 94.986551] ? vma_start_read+0xf0/0x320 [ 94.986558] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986561] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986563] ? fpregs_assert_state_consistent+0x50/0xe0 [ 94.986572] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986574] ? arch_exit_to_user_mode_prepare+0x9/0xb0 [ 94.986587] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986588] ? irqentry_exit+0x3c/0x590 [ 94.986595] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 94.986597] RIP: 0033:0x7fda4a79c3ea
Fix by extracting the character value before invoking match_char, ensuring single evaluation per outer loop.(CVE-2026-23406)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix missing bounds check on DEFAULT table in verify_dfa()
The verify_dfa() function only checks DEFAULT_TABLE bounds when the state is not differentially encoded.
When the verification loop traverses the differential encoding chain, it reads k = DEFAULT_TABLE[j] and uses k as an array index without validation. A malformed DFA with DEFAULT_TABLE[j] >= state_count, therefore, causes both out-of-bounds reads and writes.
[ 57.179855] ================================================================== [ 57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660 [ 57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993
[ 57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 57.181563] Call Trace: [ 57.181572] <TASK> [ 57.181577] dump_stack_lvl+0x5e/0x80 [ 57.181596] print_report+0xc8/0x270 [ 57.181605] ? verify_dfa+0x59a/0x660 [ 57.181608] kasan_report+0x118/0x150 [ 57.181620] ? verify_dfa+0x59a/0x660 [ 57.181623] verify_dfa+0x59a/0x660 [ 57.181627] aa_dfa_unpack+0x1610/0x1740 [ 57.181629] ? __kmalloc_cache_noprof+0x1d0/0x470 [ 57.181640] unpack_pdb+0x86d/0x46b0 [ 57.181647] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181653] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181656] ? aa_unpack_nameX+0x1a8/0x300 [ 57.181659] aa_unpack+0x20b0/0x4c30 [ 57.181662] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181664] ? stack_depot_save_flags+0x33/0x700 [ 57.181681] ? kasan_save_track+0x4f/0x80 [ 57.181683] ? kasan_save_track+0x3e/0x80 [ 57.181686] ? __kasan_kmalloc+0x93/0xb0 [ 57.181688] ? __kvmalloc_node_noprof+0x44a/0x780 [ 57.181693] ? aa_simple_write_to_buffer+0x54/0x130 [ 57.181697] ? policy_update+0x154/0x330 [ 57.181704] aa_replace_profiles+0x15a/0x1dd0 [ 57.181707] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181710] ? __kvmalloc_node_noprof+0x44a/0x780 [ 57.181712] ? aa_loaddata_alloc+0x77/0x140 [ 57.181715] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181717] ? _copy_from_user+0x2a/0x70 [ 57.181730] policy_update+0x17a/0x330 [ 57.181733] profile_replace+0x153/0x1a0 [ 57.181735] ? rw_verify_area+0x93/0x2d0 [ 57.181740] vfs_write+0x235/0xab0 [ 57.181745] ksys_write+0xb0/0x170 [ 57.181748] do_syscall_64+0x8e/0x660 [ 57.181762] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 57.181765] RIP: 0033:0x7f6192792eb2
Remove the MATCH_FLAG_DIFF_ENCODE condition to validate all DEFAULT_TABLE entries unconditionally.(CVE-2026-23407)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: add NULL checks for idev in SRv6 paths
__in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).
Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.(CVE-2026-23442)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds check
The same bounds-check bug fixed for NDP16 in the previous patch also exists in cdc_ncm_rx_verify_ndp32(). The DPE array size is validated against the total skb length without accounting for ndpoffset, allowing out-of-bounds reads when the NDP32 is placed near the end of the NTB.
Add ndpoffset to the nframes bounds check and use struct_size_t() to express the NDP-plus-DPE-array size more clearly.
Compile-tested only.(CVE-2026-23447)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: teql: Fix double-free in teql_master_xmit
Whenever a TEQL devices has a lockless Qdisc as root, qdisc_reset should be called using the seq_lock to avoid racing with the datapath. Failure to do so may cause crashes like the following:
[ 238.028993][ T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139) [ 238.029328][ T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318 [ 238.029749][ T318] [ 238.029900][ T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full) [ 238.029906][ T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 238.029910][ T318] Call Trace: [ 238.029913][ T318] <TASK> [ 238.029916][ T318] dump_stack_lvl (lib/dump_stack.c:122) [ 238.029928][ T318] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 238.029940][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029944][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) ... [ 238.029957][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029969][ T318] kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563) [ 238.029979][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029989][ T318] check_slab_allocation (mm/kasan/common.c:231) [ 238.029995][ T318] kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1)) [ 238.030004][ T318] skb_release_data (net/core/skbuff.c:1139) ... [ 238.030025][ T318] sk_skb_reason_drop (net/core/skbuff.c:1256) [ 238.030032][ T318] pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309 ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827) [ 238.030039][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) ... [ 238.030054][ T318] qdisc_reset (net/sched/sch_generic.c:1034) [ 238.030062][ T318] teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157) [ 238.030071][ T318] __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077) [ 238.030077][ T318] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 238.030089][ T318] ? __pfx_qdisc_graft (net/sched/sch_api.c:1091) [ 238.030095][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030102][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030106][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030114][ T318] tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556) ... [ 238.072958][ T318] Allocated by task 303 on cpu 5 at 238.026275s: [ 238.073392][ T318] kasan_save_stack (mm/kasan/common.c:58) [ 238.073884][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5)) [ 238.074230][ T318] __kasan_slab_alloc (mm/kasan/common.c:369) [ 238.074578][ T318] kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921) [ 238.076091][ T318] kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107)) [ 238.076450][ T318] __alloc_skb (net/core/skbuff.c:713) [ 238.076834][ T318] alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763) [ 238.077178][ T318] sock_alloc_send_pskb (net/core/sock.c:2997) [ 238.077520][ T318] packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108) [ 238.081469][ T318] [ 238.081870][ T318] Freed by task 299 on cpu 1 at 238.028496s: [ 238.082761][ T318] kasan_save_stack (mm/kasan/common.c:58) [ 238.083481][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5)) [ 238.085348][ T318] kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1)) [ 238.085900][ T318] __kasan_slab_free (mm/ ---truncated---(CVE-2026-23449)
In the Linux kernel, the following vulnerability has been resolved:
PM: runtime: Fix a race condition related to device removal
The following code in pm_runtime_work() may dereference the dev->parent pointer after the parent device has been freed:
/* Maybe the parent is now able to suspend. */
if (parent && !parent->power.ignore_children) {
spin_unlock(&dev->power.lock);
spin_lock(&parent->power.lock);
rpm_idle(parent, RPM_ASYNC);
spin_unlock(&parent->power.lock);
spin_lock(&dev->power.lock);
}
Fix this by inserting a flush_work() call in pm_runtime_remove().
Without this patch blktest block/001 triggers the following complaint sporadically:
BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pm_runtime_work Call Trace: <TASK> dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0 __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160 _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 </TASK>
Allocated by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50 __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810(CVE-2026-23452)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()
In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read.
Add a check to ensure len is positive after the decrement.(CVE-2026-23455)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case
In decode_int(), the CONS case calls get_bits(bs, 2) to read a length value, then calls get_uint(bs, len) without checking that len bytes remain in the buffer. The existing boundary check only validates the 2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint() reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte slab-out-of-bounds read.
Add a boundary check for len bytes after get_bits() and before get_uint().(CVE-2026-23456)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp()
sip_help_tcp() parses the SIP Content-Length header with simple_strtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are silently truncated before computing the SIP message boundary.
For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser.
Fix this by changing clen to unsigned long to match the return type of simple_strtoul(), and reject Content-Length values that exceed the remaining TCP payload length.(CVE-2026-23457)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()
ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the conntrack reference immediately after netlink_dump_start(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfct_help(ct), leading to a use-after-free on ct->ext.
The bug is that the netlink_dump_control has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlink_get_conntrack) properly use .start/.done callbacks for this purpose.
Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfct_help() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily.
BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133
CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: <TASK> ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0
Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180
Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0(CVE-2026-23458)
In the Linux kernel, the following vulnerability has been resolved:
spi: fix statistics allocation
The controller per-cpu statistics is not allocated until after the controller has been registered with driver core, which leaves a window where accessing the sysfs attributes can trigger a NULL-pointer dereference.
Fix this by moving the statistics allocation to controller allocation while tying its lifetime to that of the controller (rather than using implicit devres).(CVE-2026-23475)
In the Linux kernel, the following vulnerability has been resolved:
spi: fix use-after-free on controller registration failure
Make sure to deregister from driver core also in the unlikely event that per-cpu statistics allocation fails during controller registration to avoid use-after-free (of driver resources) and unclocked register accesses.(CVE-2026-31389)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: avoid overflows in ip6_datagram_send_ctl()
Yiming Qian reported :
<quote>
I believe I found a locally triggerable kernel bug in the IPv6 sendmsg
ancillary-data path that can panic the kernel via skb_under_panic()
(local DoS).
The core issue is a mismatch between:
- a 16-bit length accumulator (
struct ipv6_txoptions::opt_flen, type__u16) and - a pointer to the last provided destination-options header (
opt->dst1opt)
when multiple IPV6_DSTOPTS control messages (cmsgs) are provided.
include/net/ipv6.h:struct ipv6_txoptions::opt_flenis__u16(wrap possible). (lines 291-307, especially 298)net/ipv6/datagram.c:ip6_datagram_send_ctl():- Accepts repeated
IPV6_DSTOPTSand accumulates intoopt_flenwithout rejecting duplicates. (lines 909-933) net/ipv6/ip6_output.c:__ip6_append_data():- Uses
opt->opt_flen + opt->opt_nflento compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) net/ipv6/ip6_output.c:__ip6_make_skb():- Calls
ipv6_push_frag_opts()ifopt->opt_flenis non-zero. (lines 1930-1934) net/ipv6/exthdrs.c:ipv6_push_frag_opts()/ipv6_push_exthdr():-
Push size comes from
ipv6_optlen(opt->dst1opt)(based on the pointed-to header). (lines 1179-1185 and 1206-1211) -
opt_flenis a 16-bit accumulator: -
include/net/ipv6.h:298defines__u16 opt_flen; /* after fragment hdr */. -
ip6_datagram_send_ctl()accepts repeatedIPV6_DSTOPTScmsgs and incrementsopt_fleneach time: -
In
net/ipv6/datagram.c:909-933, forIPV6_DSTOPTS: - It computes
len = ((hdr->hdrlen + 1) << 3); - It checks
CAP_NET_RAWusingns_capable(net->user_ns, CAP_NET_RAW). (line 922) - Then it does:
opt->opt_flen += len;(line 927)opt->dst1opt = hdr;(line 928)
There is no duplicate rejection here (unlike the legacy
IPV6_2292DSTOPTS path which rejects duplicates at
net/ipv6/datagram.c:901-904).
If enough large IPV6_DSTOPTS cmsgs are provided, opt_flen wraps
while dst1opt still points to a large (2048-byte)
destination-options header.
In the attached PoC (poc.c):
- 32 cmsgs with
hdrlen=255=>len = (255+1)*8 = 2048 - 1 cmsg with
hdrlen=0=>len = 8 - Total increment:
32*2048 + 8 = 65544, so(__u16)opt_flen == 8 -
The last cmsg is 2048 bytes, so
dst1optpoints to a 2048-byte header. -
The transmit path sizes headers using the wrapped
opt_flen: -
In
net/ipv6/ip6_output.c:1463-1465: headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;
With wrapped opt_flen, headersize/headroom decisions underestimate
what will be pushed later.
-
When building the final skb, the actual push length comes from
dst1optand is not limited by wrappedopt_flen: -
In
net/ipv6/ip6_output.c:1930-1934: if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);- In
net/ipv6/exthdrs.c:1206-1211,ipv6_push_frag_opts()pushesdst1optviaipv6_push_exthdr(). - In
net/ipv6/exthdrs.c:1179-1184,ipv6_push_exthdr()does: skb_push(skb, ipv6_optlen(opt));memcpy(h, opt, ipv6_optlen(opt));
With insufficient headroom, skb_push() underflows and triggers
skb_under_panic() -> BUG():
net/core/skbuff.c:2669-2675(skb_push()callsskb_under_panic())-
net/core/skbuff.c:207-214(skb_panic()ends inBUG()) -
The
IPV6_DSTOPTScmsg path requiresCAP_NET_RAWin the target netns user namespace (ns_capable(net->user_ns, CAP_NET_RAW)). - Root (or any task with
CAP_NET_RAW) can trigger this without user namespaces. -
An unprivileged
uid=1000user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespacedCAP_NET_RAW(the attached PoC does this). -
Local denial of service: kernel BUG/panic (system crash). - ---truncated---(CVE-2026-31415)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_log: account for netlink header size
This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size.
This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.(CVE-2026-31416)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp
process_sdp() declares union nf_inet_addr rtp_addr on the stack and passes it to the nf_nat_sip sdp_session hook after walking the SDP media descriptions. However rtp_addr is only initialized inside the media loop when a recognized media type with a non-zero port is found.
If the SDP body contains no m= lines, only inactive media sections (m=audio 0 ...) or only unrecognized media types, rtp_addr is never assigned. Despite that, the function still calls hooks->sdp_session() with &rtp_addr, causing nf_nat_sdp_session() to format the stale stack value as an IP address and rewrite the SDP session owner and connection lines with it.
With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this results in the session-level o= and c= addresses being rewritten to 0.0.0.0 for inactive SDP sessions. Without stack auto-init the rewritten address is whatever happened to be on the stack.
Fix this by pre-initializing rtp_addr from the session-level connection address (caddr) when available, and tracking via a have_rtp_addr flag whether any valid address was established. Skip the sdp_session hook entirely when no valid address exists.(CVE-2026-31427)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD
__build_packet_message() manually constructs the NFULA_PAYLOAD netlink attribute using skb_put() and skb_copy_bits(), bypassing the standard nla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes are allocated (including NLA alignment padding), only data_len bytes of actual packet data are copied. The trailing nla_padlen(data_len) bytes (1-3 when data_len is not 4-byte aligned) are never initialized, leaking stale heap contents to userspace via the NFLOG netlink socket.
Replace the manual attribute construction with nla_reserve(), which handles the tailroom check, header setup, and padding zeroing via __nla_reserve(). The subsequent skb_copy_bits() fills in the payload data on top of the properly initialized attribute.(CVE-2026-31428)
In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - Revert to operating out-of-place\n\nThis mostly reverts commit 72548b093ee3 except for the copying of the associated data.\n\nThere is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.(CVE-2026-31431)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-source-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"perf-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"python3-perf-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.0.7.134.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-source-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"perf-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"python3-perf-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-145.0.7.134.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.(CVE-2025-27558)\n\nIn the Linux kernel, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuacce: fix cdev handling in the cleanup path\n\nWhen cdev_device_add fails, it internally releases the cdev memory,\nand if cdev_device_del is then executed, it will cause a hang error.\nTo fix it, we check the return value of cdev_device_add() and clear\nuacce-\u0026gt;cdev to avoid calling cdev_device_del in the uacce_remove.(CVE-2026-23096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_ife: Fix metalist update behavior\n\nWhenever an ife action replace changes the metalist, instead of\nreplacing the old data on the metalist, the current ife code is appending\nthe new metadata. Aside from being innapropriate behavior, this may lead\nto an unbounded addition of metadata to the metalist which might cause an\nout of bounds error when running the encode op:\n\n[ 138.423369][ C1] ==================================================================\n[ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ife_tlv_meta_encode (net/ife/ife.c:168)\n[ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ife_out_out_bou/255\n[ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full)\n[ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n[ 138.425800][ C1] Call Trace:\n[ 138.425804][ C1] \u0026lt;IRQ\u0026gt;\n[ 138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122)\n[ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n[ 138.425839][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 138.425844][ C1] ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1))\n[ 138.425853][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)\n[ 138.425859][ C1] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597)\n[ 138.425868][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)\n[ 138.425878][ C1] kasan_check_range (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1))\n[ 138.425884][ C1] __asan_memset (mm/kasan/shadow.c:84 (discriminator 2))\n[ 138.425889][ C1] ife_tlv_meta_encode (net/ife/ife.c:168)\n[ 138.425893][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:171)\n[ 138.425898][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 138.425903][ C1] ife_encode_meta_u16 (net/sched/act_ife.c:57)\n[ 138.425910][ C1] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114)\n[ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3))\n[ 138.425921][ C1] ? __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45)\n[ 138.425927][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 138.425931][ C1] tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879)\n\nTo solve this issue, fix the replace behavior by adding the metalist to\nthe ife rcu data structure.(CVE-2026-23378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nicmp: fix NULL pointer dereference in icmp_tag_validation()\n\nicmp_tag_validation() unconditionally dereferences the result of\nrcu_dereference(inet_protos[proto]) without checking for NULL.\nThe inet_protos[] array is sparse -- only about 15 of 256 protocol\nnumbers have registered handlers. When ip_no_pmtu_disc is set to 3\n(hardened PMTU mode) and the kernel receives an ICMP Fragmentation\nNeeded error with a quoted inner IP header containing an unregistered\nprotocol number, the NULL dereference causes a kernel panic in\nsoftirq context.\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143)\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n icmp_rcv (net/ipv4/icmp.c:1527)\n ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207)\n ip_local_deliver_finish (net/ipv4/ip_input.c:242)\n ip_local_deliver (net/ipv4/ip_input.c:262)\n ip_rcv (net/ipv4/ip_input.c:573)\n __netif_receive_skb_one_core (net/core/dev.c:6164)\n process_backlog (net/core/dev.c:6628)\n handle_softirqs (kernel/softirq.c:561)\n \u0026lt;/IRQ\u0026gt;\n\nAdd a NULL check before accessing icmp_strict_tag_validation. If the\nprotocol has no registered handler, return false since it cannot\nperform strict tag validation.(CVE-2026-23398)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix side-effect bug in match_char() macro usage\n\nThe match_char() macro evaluates its character parameter multiple\ntimes when traversing differential encoding chains. When invoked\nwith *str++, the string pointer advances on each iteration of the\ninner do-while loop, causing the DFA to check different characters\nat each iteration and therefore skip input characters.\nThis results in out-of-bounds reads when the pointer advances past\nthe input buffer boundary.\n\n[ 94.984676] ==================================================================\n[ 94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760\n[ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976\n\n[ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)\n[ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 94.986329] Call Trace:\n[ 94.986341] \u0026lt;TASK\u0026gt;\n[ 94.986347] dump_stack_lvl+0x5e/0x80\n[ 94.986374] print_report+0xc8/0x270\n[ 94.986384] ? aa_dfa_match+0x5ae/0x760\n[ 94.986388] kasan_report+0x118/0x150\n[ 94.986401] ? aa_dfa_match+0x5ae/0x760\n[ 94.986405] aa_dfa_match+0x5ae/0x760\n[ 94.986408] __aa_path_perm+0x131/0x400\n[ 94.986418] aa_path_perm+0x219/0x2f0\n[ 94.986424] apparmor_file_open+0x345/0x570\n[ 94.986431] security_file_open+0x5c/0x140\n[ 94.986442] do_dentry_open+0x2f6/0x1120\n[ 94.986450] vfs_open+0x38/0x2b0\n[ 94.986453] ? may_open+0x1e2/0x2b0\n[ 94.986466] path_openat+0x231b/0x2b30\n[ 94.986469] ? __x64_sys_openat+0xf8/0x130\n[ 94.986477] do_file_open+0x19d/0x360\n[ 94.986487] do_sys_openat2+0x98/0x100\n[ 94.986491] __x64_sys_openat+0xf8/0x130\n[ 94.986499] do_syscall_64+0x8e/0x660\n[ 94.986515] ? count_memcg_events+0x15f/0x3c0\n[ 94.986526] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986540] ? handle_mm_fault+0x1639/0x1ef0\n[ 94.986551] ? vma_start_read+0xf0/0x320\n[ 94.986558] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986561] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986563] ? fpregs_assert_state_consistent+0x50/0xe0\n[ 94.986572] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986574] ? arch_exit_to_user_mode_prepare+0x9/0xb0\n[ 94.986587] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986588] ? irqentry_exit+0x3c/0x590\n[ 94.986595] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 94.986597] RIP: 0033:0x7fda4a79c3ea\n\nFix by extracting the character value before invoking match_char,\nensuring single evaluation per outer loop.(CVE-2026-23406)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix missing bounds check on DEFAULT table in verify_dfa()\n\nThe verify_dfa() function only checks DEFAULT_TABLE bounds when the state\nis not differentially encoded.\n\nWhen the verification loop traverses the differential encoding chain,\nit reads k = DEFAULT_TABLE[j] and uses k as an array index without\nvalidation. A malformed DFA with DEFAULT_TABLE[j] \u0026gt;= state_count,\ntherefore, causes both out-of-bounds reads and writes.\n\n[ 57.179855] ==================================================================\n[ 57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660\n[ 57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993\n\n[ 57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)\n[ 57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 57.181563] Call Trace:\n[ 57.181572] \u0026lt;TASK\u0026gt;\n[ 57.181577] dump_stack_lvl+0x5e/0x80\n[ 57.181596] print_report+0xc8/0x270\n[ 57.181605] ? verify_dfa+0x59a/0x660\n[ 57.181608] kasan_report+0x118/0x150\n[ 57.181620] ? verify_dfa+0x59a/0x660\n[ 57.181623] verify_dfa+0x59a/0x660\n[ 57.181627] aa_dfa_unpack+0x1610/0x1740\n[ 57.181629] ? __kmalloc_cache_noprof+0x1d0/0x470\n[ 57.181640] unpack_pdb+0x86d/0x46b0\n[ 57.181647] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181653] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181656] ? aa_unpack_nameX+0x1a8/0x300\n[ 57.181659] aa_unpack+0x20b0/0x4c30\n[ 57.181662] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181664] ? stack_depot_save_flags+0x33/0x700\n[ 57.181681] ? kasan_save_track+0x4f/0x80\n[ 57.181683] ? kasan_save_track+0x3e/0x80\n[ 57.181686] ? __kasan_kmalloc+0x93/0xb0\n[ 57.181688] ? __kvmalloc_node_noprof+0x44a/0x780\n[ 57.181693] ? aa_simple_write_to_buffer+0x54/0x130\n[ 57.181697] ? policy_update+0x154/0x330\n[ 57.181704] aa_replace_profiles+0x15a/0x1dd0\n[ 57.181707] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181710] ? __kvmalloc_node_noprof+0x44a/0x780\n[ 57.181712] ? aa_loaddata_alloc+0x77/0x140\n[ 57.181715] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181717] ? _copy_from_user+0x2a/0x70\n[ 57.181730] policy_update+0x17a/0x330\n[ 57.181733] profile_replace+0x153/0x1a0\n[ 57.181735] ? rw_verify_area+0x93/0x2d0\n[ 57.181740] vfs_write+0x235/0xab0\n[ 57.181745] ksys_write+0xb0/0x170\n[ 57.181748] do_syscall_64+0x8e/0x660\n[ 57.181762] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 57.181765] RIP: 0033:0x7f6192792eb2\n\nRemove the MATCH_FLAG_DIFF_ENCODE condition to validate all DEFAULT_TABLE\nentries unconditionally.(CVE-2026-23407)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: add NULL checks for idev in SRv6 paths\n\n__in6_dev_get() can return NULL when the device has no IPv6 configuration\n(e.g. MTU \u0026lt; IPV6_MIN_MTU or after NETDEV_UNREGISTER).\n\nAdd NULL checks for idev returned by __in6_dev_get() in both\nseg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL\npointer dereferences.(CVE-2026-23442)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds check\n\nThe same bounds-check bug fixed for NDP16 in the previous patch also\nexists in cdc_ncm_rx_verify_ndp32(). The DPE array size is validated\nagainst the total skb length without accounting for ndpoffset, allowing\nout-of-bounds reads when the NDP32 is placed near the end of the NTB.\n\nAdd ndpoffset to the nframes bounds check and use struct_size_t() to\nexpress the NDP-plus-DPE-array size more clearly.\n\nCompile-tested only.(CVE-2026-23447)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: teql: Fix double-free in teql_master_xmit\n\nWhenever a TEQL devices has a lockless Qdisc as root, qdisc_reset should\nbe called using the seq_lock to avoid racing with the datapath. Failure\nto do so may cause crashes like the following:\n\n[ 238.028993][ T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139)\n[ 238.029328][ T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318\n[ 238.029749][ T318]\n[ 238.029900][ T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full)\n[ 238.029906][ T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n[ 238.029910][ T318] Call Trace:\n[ 238.029913][ T318] \u0026lt;TASK\u0026gt;\n[ 238.029916][ T318] dump_stack_lvl (lib/dump_stack.c:122)\n[ 238.029928][ T318] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n[ 238.029940][ T318] ? skb_release_data (net/core/skbuff.c:1139)\n[ 238.029944][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n...\n[ 238.029957][ T318] ? skb_release_data (net/core/skbuff.c:1139)\n[ 238.029969][ T318] kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563)\n[ 238.029979][ T318] ? skb_release_data (net/core/skbuff.c:1139)\n[ 238.029989][ T318] check_slab_allocation (mm/kasan/common.c:231)\n[ 238.029995][ T318] kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1))\n[ 238.030004][ T318] skb_release_data (net/core/skbuff.c:1139)\n...\n[ 238.030025][ T318] sk_skb_reason_drop (net/core/skbuff.c:1256)\n[ 238.030032][ T318] pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309 ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827)\n[ 238.030039][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n...\n[ 238.030054][ T318] qdisc_reset (net/sched/sch_generic.c:1034)\n[ 238.030062][ T318] teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157)\n[ 238.030071][ T318] __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077)\n[ 238.030077][ T318] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159)\n[ 238.030089][ T318] ? __pfx_qdisc_graft (net/sched/sch_api.c:1091)\n[ 238.030095][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 238.030102][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 238.030106][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 238.030114][ T318] tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556)\n...\n[ 238.072958][ T318] Allocated by task 303 on cpu 5 at 238.026275s:\n[ 238.073392][ T318] kasan_save_stack (mm/kasan/common.c:58)\n[ 238.073884][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))\n[ 238.074230][ T318] __kasan_slab_alloc (mm/kasan/common.c:369)\n[ 238.074578][ T318] kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921)\n[ 238.076091][ T318] kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107))\n[ 238.076450][ T318] __alloc_skb (net/core/skbuff.c:713)\n[ 238.076834][ T318] alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763)\n[ 238.077178][ T318] sock_alloc_send_pskb (net/core/sock.c:2997)\n[ 238.077520][ T318] packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108)\n[ 238.081469][ T318]\n[ 238.081870][ T318] Freed by task 299 on cpu 1 at 238.028496s:\n[ 238.082761][ T318] kasan_save_stack (mm/kasan/common.c:58)\n[ 238.083481][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))\n[ 238.085348][ T318] kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1))\n[ 238.085900][ T318] __kasan_slab_free (mm/\n---truncated---(CVE-2026-23449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM: runtime: Fix a race condition related to device removal\n\nThe following code in pm_runtime_work() may dereference the dev-\u0026gt;parent\npointer after the parent device has been freed:\n\n\t/* Maybe the parent is now able to suspend. */\n\tif (parent \u0026amp;\u0026amp; !parent-\u0026gt;power.ignore_children) {\n\t\tspin_unlock(\u0026amp;dev-\u0026gt;power.lock);\n\n\t\tspin_lock(\u0026amp;parent-\u0026gt;power.lock);\n\t\trpm_idle(parent, RPM_ASYNC);\n\t\tspin_unlock(\u0026amp;parent-\u0026gt;power.lock);\n\n\t\tspin_lock(\u0026amp;dev-\u0026gt;power.lock);\n\t}\n\nFix this by inserting a flush_work() call in pm_runtime_remove().\n\nWithout this patch blktest block/001 triggers the following complaint\nsporadically:\n\nBUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160\nRead of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081\nWorkqueue: pm pm_runtime_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x61/0x80\n print_address_description.constprop.0+0x8b/0x310\n print_report+0xfd/0x1d7\n kasan_report+0xd8/0x1d0\n __kasan_check_byte+0x42/0x60\n lock_acquire.part.0+0x38/0x230\n lock_acquire+0x70/0x160\n _raw_spin_lock+0x36/0x50\n rpm_suspend+0xc6a/0xfe0\n rpm_idle+0x578/0x770\n pm_runtime_work+0xee/0x120\n process_one_work+0xde3/0x1410\n worker_thread+0x5eb/0xfe0\n kthread+0x37b/0x480\n ret_from_fork+0x6cb/0x920\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 4314:\n kasan_save_stack+0x2a/0x50\n kasan_save_track+0x18/0x40\n kasan_save_alloc_info+0x3d/0x50\n __kasan_kmalloc+0xa0/0xb0\n __kmalloc_noprof+0x311/0x990\n scsi_alloc_target+0x122/0xb60 [scsi_mod]\n __scsi_scan_target+0x101/0x460 [scsi_mod]\n scsi_scan_channel+0x179/0x1c0 [scsi_mod]\n scsi_scan_host_selected+0x259/0x2d0 [scsi_mod]\n store_scan+0x2d2/0x390 [scsi_mod]\n dev_attr_store+0x43/0x80\n sysfs_kf_write+0xde/0x140\n kernfs_fop_write_iter+0x3ef/0x670\n vfs_write+0x506/0x1470\n ksys_write+0xfd/0x230\n __x64_sys_write+0x76/0xc0\n x64_sys_call+0x213/0x1810\n do_syscall_64+0xee/0xfc0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFreed by task 4314:\n kasan_save_stack+0x2a/0x50\n kasan_save_track+0x18/0x40\n kasan_save_free_info+0x3f/0x50\n __kasan_slab_free+0x67/0x80\n kfree+0x225/0x6c0\n scsi_target_dev_release+0x3d/0x60 [scsi_mod]\n device_release+0xa3/0x220\n kobject_cleanup+0x105/0x3a0\n kobject_put+0x72/0xd0\n put_device+0x17/0x20\n scsi_device_dev_release+0xacf/0x12c0 [scsi_mod]\n device_release+0xa3/0x220\n kobject_cleanup+0x105/0x3a0\n kobject_put+0x72/0xd0\n put_device+0x17/0x20\n scsi_device_put+0x7f/0xc0 [scsi_mod]\n sdev_store_delete+0xa5/0x120 [scsi_mod]\n dev_attr_store+0x43/0x80\n sysfs_kf_write+0xde/0x140\n kernfs_fop_write_iter+0x3ef/0x670\n vfs_write+0x506/0x1470\n ksys_write+0xfd/0x230\n __x64_sys_write+0x76/0xc0\n x64_sys_call+0x213/0x1810(CVE-2026-23452)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_h323: check for zero length in DecodeQ931()\n\nIn DecodeQ931(), the UserUserIE code path reads a 16-bit length from\nthe packet, then decrements it by 1 to skip the protocol discriminator\nbyte before passing it to DecodeH323_UserInformation(). If the encoded\nlength is 0, the decrement wraps to -1, which is then passed as a\nlarge value to the decoder, leading to an out-of-bounds read.\n\nAdd a check to ensure len is positive after the decrement.(CVE-2026-23455)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case\n\nIn decode_int(), the CONS case calls get_bits(bs, 2) to read a length\nvalue, then calls get_uint(bs, len) without checking that len bytes\nremain in the buffer. The existing boundary check only validates the\n2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint()\nreads. This allows a malformed H.323/RAS packet to cause a 1-4 byte\nslab-out-of-bounds read.\n\nAdd a boundary check for len bytes after get_bits() and before\nget_uint().(CVE-2026-23456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp()\n\nsip_help_tcp() parses the SIP Content-Length header with\nsimple_strtoul(), which returns unsigned long, but stores the result in\nunsigned int clen. On 64-bit systems, values exceeding UINT_MAX are\nsilently truncated before computing the SIP message boundary.\n\nFor example, Content-Length 4294967328 (2^32 + 32) is truncated to 32,\ncausing the parser to miscalculate where the current message ends. The\nloop then treats trailing data in the TCP segment as a second SIP\nmessage and processes it through the SDP parser.\n\nFix this by changing clen to unsigned long to match the return type of\nsimple_strtoul(), and reject Content-Length values that exceed the\nremaining TCP payload length.(CVE-2026-23457)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()\n\nctnetlink_dump_exp_ct() stores a conntrack pointer in cb-\u0026gt;data for the\nnetlink dump callback ctnetlink_exp_ct_dump_table(), but drops the\nconntrack reference immediately after netlink_dump_start(). When the\ndump spans multiple rounds, the second recvmsg() triggers the dump\ncallback which dereferences the now-freed conntrack via nfct_help(ct),\nleading to a use-after-free on ct-\u0026gt;ext.\n\nThe bug is that the netlink_dump_control has no .start or .done\ncallbacks to manage the conntrack reference across dump rounds. Other\ndump functions in the same file (e.g. ctnetlink_get_conntrack) properly\nuse .start/.done callbacks for this purpose.\n\nFix this by adding .start and .done callbacks that hold and release the\nconntrack reference for the duration of the dump, and move the\nnfct_help() call after the cb-\u0026gt;args[0] early-return check in the dump\ncallback to avoid dereferencing ct-\u0026gt;ext unnecessarily.\n\n BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0\n Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133\n\n CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ctnetlink_exp_ct_dump_table+0x4f/0x2e0\n netlink_dump+0x333/0x880\n netlink_recvmsg+0x3e2/0x4b0\n ? aa_sk_perm+0x184/0x450\n sock_recvmsg+0xde/0xf0\n\n Allocated by task 133:\n kmem_cache_alloc_noprof+0x134/0x440\n __nf_conntrack_alloc+0xa8/0x2b0\n ctnetlink_create_conntrack+0xa1/0x900\n ctnetlink_new_conntrack+0x3cf/0x7d0\n nfnetlink_rcv_msg+0x48e/0x510\n netlink_rcv_skb+0xc9/0x1f0\n nfnetlink_rcv+0xdb/0x220\n netlink_unicast+0x3ec/0x590\n netlink_sendmsg+0x397/0x690\n __sys_sendmsg+0xf4/0x180\n\n Freed by task 0:\n slab_free_after_rcu_debug+0xad/0x1e0\n rcu_core+0x5c3/0x9c0(CVE-2026-23458)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: fix statistics allocation\n\nThe controller per-cpu statistics is not allocated until after the\ncontroller has been registered with driver core, which leaves a window\nwhere accessing the sysfs attributes can trigger a NULL-pointer\ndereference.\n\nFix this by moving the statistics allocation to controller allocation\nwhile tying its lifetime to that of the controller (rather than using\nimplicit devres).(CVE-2026-23475)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: fix use-after-free on controller registration failure\n\nMake sure to deregister from driver core also in the unlikely event that\nper-cpu statistics allocation fails during controller registration to\navoid use-after-free (of driver resources) and unclocked register\naccesses.(CVE-2026-31389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: avoid overflows in ip6_datagram_send_ctl()\n\nYiming Qian reported :\n\u0026lt;quote\u0026gt;\n I believe I found a locally triggerable kernel bug in the IPv6 sendmsg\n ancillary-data path that can panic the kernel via `skb_under_panic()`\n (local DoS).\n\n The core issue is a mismatch between:\n\n - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type\n `__u16`) and\n - a pointer to the *last* provided destination-options header (`opt-\u0026gt;dst1opt`)\n\n when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided.\n\n - `include/net/ipv6.h`:\n - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible).\n (lines 291-307, especially 298)\n - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`:\n - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen`\n without rejecting duplicates. (lines 909-933)\n - `net/ipv6/ip6_output.c:__ip6_append_data()`:\n - Uses `opt-\u0026gt;opt_flen + opt-\u0026gt;opt_nflen` to compute header\n sizes/headroom decisions. (lines 1448-1466, especially 1463-1465)\n - `net/ipv6/ip6_output.c:__ip6_make_skb()`:\n - Calls `ipv6_push_frag_opts()` if `opt-\u0026gt;opt_flen` is non-zero.\n (lines 1930-1934)\n - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`:\n - Push size comes from `ipv6_optlen(opt-\u0026gt;dst1opt)` (based on the\n pointed-to header). (lines 1179-1185 and 1206-1211)\n\n 1. `opt_flen` is a 16-bit accumulator:\n\n - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`.\n\n 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs\n and increments `opt_flen` each time:\n\n - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`:\n - It computes `len = ((hdr-\u0026gt;hdrlen + 1) \u0026lt;\u0026lt; 3);`\n - It checks `CAP_NET_RAW` using `ns_capable(net-\u0026gt;user_ns,\n CAP_NET_RAW)`. (line 922)\n - Then it does:\n - `opt-\u0026gt;opt_flen += len;` (line 927)\n - `opt-\u0026gt;dst1opt = hdr;` (line 928)\n\n There is no duplicate rejection here (unlike the legacy\n `IPV6_2292DSTOPTS` path which rejects duplicates at\n `net/ipv6/datagram.c:901-904`).\n\n If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps\n while `dst1opt` still points to a large (2048-byte)\n destination-options header.\n\n In the attached PoC (`poc.c`):\n\n - 32 cmsgs with `hdrlen=255` =\u0026gt; `len = (255+1)*8 = 2048`\n - 1 cmsg with `hdrlen=0` =\u0026gt; `len = 8`\n - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8`\n - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header.\n\n 3. The transmit path sizes headers using the wrapped `opt_flen`:\n\n- In `net/ipv6/ip6_output.c:1463-1465`:\n - `headersize = sizeof(struct ipv6hdr) + (opt ? opt-\u0026gt;opt_flen +\n opt-\u0026gt;opt_nflen : 0) + ...;`\n\n With wrapped `opt_flen`, `headersize`/headroom decisions underestimate\n what will be pushed later.\n\n 4. When building the final skb, the actual push length comes from\n `dst1opt` and is not limited by wrapped `opt_flen`:\n\n - In `net/ipv6/ip6_output.c:1930-1934`:\n - `if (opt-\u0026gt;opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);`\n - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes\n `dst1opt` via `ipv6_push_exthdr()`.\n - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does:\n - `skb_push(skb, ipv6_optlen(opt));`\n - `memcpy(h, opt, ipv6_optlen(opt));`\n\n With insufficient headroom, `skb_push()` underflows and triggers\n `skb_under_panic()` -\u0026gt; `BUG()`:\n\n - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`)\n - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`)\n\n - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target\n netns user namespace (`ns_capable(net-\u0026gt;user_ns, CAP_NET_RAW)`).\n - Root (or any task with `CAP_NET_RAW`) can trigger this without user\n namespaces.\n - An unprivileged `uid=1000` user can trigger this if unprivileged\n user namespaces are enabled and it can create a userns+netns to obtain\n namespaced `CAP_NET_RAW` (the attached PoC does this).\n\n - Local denial of service: kernel BUG/panic (system crash).\n -\n---truncated---(CVE-2026-31415)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_log: account for netlink header size\n\nThis is a followup to an old bug fix: NLMSG_DONE needs to account\nfor the netlink header size, not just the attribute size.\n\nThis can result in a WARN splat + drop of the netlink message,\nbut other than this there are no ill effects.(CVE-2026-31416)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp\n\nprocess_sdp() declares union nf_inet_addr rtp_addr on the stack and\npasses it to the nf_nat_sip sdp_session hook after walking the SDP\nmedia descriptions. However rtp_addr is only initialized inside the\nmedia loop when a recognized media type with a non-zero port is found.\n\nIf the SDP body contains no m= lines, only inactive media sections\n(m=audio 0 ...) or only unrecognized media types, rtp_addr is never\nassigned. Despite that, the function still calls hooks-\u0026gt;sdp_session()\nwith \u0026amp;rtp_addr, causing nf_nat_sdp_session() to format the stale stack\nvalue as an IP address and rewrite the SDP session owner and connection\nlines with it.\n\nWith CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this\nresults in the session-level o= and c= addresses being rewritten to\n0.0.0.0 for inactive SDP sessions. Without stack auto-init the\nrewritten address is whatever happened to be on the stack.\n\nFix this by pre-initializing rtp_addr from the session-level connection\naddress (caddr) when available, and tracking via a have_rtp_addr flag\nwhether any valid address was established. Skip the sdp_session hook\nentirely when no valid address exists.(CVE-2026-31427)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD\n\n__build_packet_message() manually constructs the NFULA_PAYLOAD netlink\nattribute using skb_put() and skb_copy_bits(), bypassing the standard\nnla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes\nare allocated (including NLA alignment padding), only data_len bytes\nof actual packet data are copied. The trailing nla_padlen(data_len)\nbytes (1-3 when data_len is not 4-byte aligned) are never initialized,\nleaking stale heap contents to userspace via the NFLOG netlink socket.\n\nReplace the manual attribute construction with nla_reserve(), which\nhandles the tailroom check, header setup, and padding zeroing via\n__nla_reserve(). The subsequent skb_copy_bits() fills in the payload\ndata on top of the properly initialized attribute.(CVE-2026-31428)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\ncrypto: algif_aead - Revert to operating out-of-place\\n\\nThis mostly reverts commit 72548b093ee3 except for the copying of the associated data.\\n\\nThere is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.(CVE-2026-31431)",
"id": "OESA-2026-2176",
"modified": "2026-08-06T11:11:09Z",
"published": "2026-05-03T11:11:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2176"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27558"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23096"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23378"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23398"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23406"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23407"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23442"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23447"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23449"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23452"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23455"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23456"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23457"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23458"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23475"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31389"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31415"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31416"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31428"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31431"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-27558",
"CVE-2025-71089",
"CVE-2026-23096",
"CVE-2026-23378",
"CVE-2026-23398",
"CVE-2026-23406",
"CVE-2026-23407",
"CVE-2026-23442",
"CVE-2026-23447",
"CVE-2026-23449",
"CVE-2026-23452",
"CVE-2026-23455",
"CVE-2026-23456",
"CVE-2026-23457",
"CVE-2026-23458",
"CVE-2026-23475",
"CVE-2026-31389",
"CVE-2026-31415",
"CVE-2026-31416",
"CVE-2026-31427",
"CVE-2026-31428",
"CVE-2026-31431"
]
}
OESA-2026-2232 (CVE-2025-71089)
Vulnerability from osv_openeuler – Published: 2026-05-09 11:11 – Updated: 2026-08-06 11:11 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: add NULL checks for idev in SRv6 paths
__in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).
Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.(CVE-2026-23442)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: add missing netlink policy validations
Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink.
These attributes are used by the kernel without any validation. Extend the netlink policies accordingly.
Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..]
and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.(CVE-2026-31407)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: drop logically empty buckets in mtype_del
mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots.
Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.(CVE-2026-31418)
In the Linux kernel, the following vulnerability has been resolved:
bridge: mrp: reject zero test interval to avoid OOM panic
br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock.
The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames.
Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.(CVE-2026-31420)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()
m2sm() converts a u32 slope to a u64 scaled value. For large inputs
(e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores
the difference of two such u64 values in a u32 variable dsm and
uses it as a divisor. When the difference is exactly 2^32 the
truncation yields zero, causing a divide-by-zero oops in the
concave-curve intersection path:
Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...]
Widen dsm to u64 and replace do_div() with div64_u64() so the full
difference is preserved.(CVE-2026-31423)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP
Weiming Shi says:
xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_ constants. This is only correct for families whose hook layout matches NF_INET_: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING).
ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: <TASK> nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) </TASK> Kernel panic - not syncing: Fatal exception in interrupt
Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports:
- arpt_CLASSIFY
- arpt_mangle
- arpt_MARK
that provide explicit NFPROTO_ARP match/target declarations.(CVE-2026-31424)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: ctxfi: Limit PTP to a single page
Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic.
ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault:
BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged.(CVE-2026-31602)
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: flowlabel: defer exclusive option free until RCU teardown
ip6fl_seq_show() walks the global flowlabel hash under the seq-file
RCU read-side lock and prints fl->opt->opt_nflen when an option block
is present.
Exclusive flowlabels currently free fl->opt as soon as fl->users
drops to zero in fl_release(). However, the surrounding
struct ip6_flowlabel remains visible in the global hash table until
later garbage collection removes it and fl_free_rcu() finally tears it
down.
A concurrent /proc/net/ip6_flowlabel reader can therefore race that
early kfree() and dereference freed option state, triggering a crash
in ip6fl_seq_show().
Fix this by keeping fl->opt alive until fl_free_rcu(). That matches
the lifetime already required for the enclosing flowlabel while readers
can still reach it under RCU.(CVE-2026-31680)
In the Linux kernel, the following vulnerability has been resolved:
perf/x86: Fix potential bad container_of in intel_pmu_hw_config
Auto counter reload may have a group of events with software events present within it. The software event PMU isn't the x86_hybrid_pmu and a container_of operation in intel_pmu_set_acr_caused_constr (via the hybrid helper) could cause out of bound memory reads. Avoid this by guarding the call to intel_pmu_set_acr_caused_constr with an is_x86_event check.(CVE-2026-31782)
| URL | Type | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-debugsource-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-devel-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-extra-modules-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-headers-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-source-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-tools-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"perf-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"perf-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"python3-perf-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.0.9.140.oe2403sp3.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-debugsource-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-devel-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-extra-modules-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-headers-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-source-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-tools-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"perf-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"perf-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"python3-perf-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-145.0.9.140.oe2403sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: add NULL checks for idev in SRv6 paths\n\n__in6_dev_get() can return NULL when the device has no IPv6 configuration\n(e.g. MTU \u0026lt; IPV6_MIN_MTU or after NETDEV_UNREGISTER).\n\nAdd NULL checks for idev returned by __in6_dev_get() in both\nseg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL\npointer dereferences.(CVE-2026-23442)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: add missing netlink policy validations\n\nHyunwoo Kim reports out-of-bounds access in sctp and ctnetlink.\n\nThese attributes are used by the kernel without any validation.\nExtend the netlink policies accordingly.\n\nQuoting the reporter:\n nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE\n value directly to ct-\u0026gt;proto.sctp.state without checking that it is\n within the valid range. [..]\n\n and: ... with exp-\u0026gt;dir = 100, the access at\n ct-\u0026gt;master-\u0026gt;tuplehash[100] reads 5600 bytes past the start of a\n 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by\n UBSAN.(CVE-2026-31407)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: drop logically empty buckets in mtype_del\n\nmtype_del() counts empty slots below n-\u0026gt;pos in k, but it only drops the\nbucket when both n-\u0026gt;pos and k are zero. This misses buckets whose live\nentries have all been removed while n-\u0026gt;pos still points past deleted slots.\n\nTreat a bucket as empty when all positions below n-\u0026gt;pos are unused and\nrelease it directly instead of shrinking it further.(CVE-2026-31418)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: mrp: reject zero test interval to avoid OOM panic\n\nbr_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied\ninterval value from netlink without validation. When interval is 0,\nusecs_to_jiffies(0) yields 0, causing the delayed work\n(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule\nitself with zero delay. This creates a tight loop on system_percpu_wq\nthat allocates and transmits MRP test frames at maximum rate, exhausting\nall system memory and causing a kernel panic via OOM deadlock.\n\nThe same zero-interval issue applies to br_mrp_start_in_test_parse()\nfor interconnect test frames.\n\nUse NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both\nIFLA_BRIDGE_MRP_START_TEST_INTERVAL and\nIFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the\nnetlink attribute parsing layer before the value ever reaches the\nworkqueue scheduling code. This is consistent with how other bridge\nsubsystems (br_fdb, br_mst) enforce range constraints on netlink\nattributes.(CVE-2026-31420)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_hfsc: fix divide-by-zero in rtsc_min()\n\nm2sm() converts a u32 slope to a u64 scaled value. For large inputs\n(e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores\nthe difference of two such u64 values in a u32 variable `dsm` and\nuses it as a divisor. When the difference is exactly 2^32 the\ntruncation yields zero, causing a divide-by-zero oops in the\nconcave-curve intersection path:\n\n Oops: divide error: 0000\n RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601)\n Call Trace:\n init_ed (net/sched/sch_hfsc.c:629)\n hfsc_enqueue (net/sched/sch_hfsc.c:1569)\n [...]\n\nWiden `dsm` to u64 and replace do_div() with div64_u64() so the full\ndifference is preserved.(CVE-2026-31423)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP\n\nWeiming Shi says:\n\nxt_match and xt_target structs registered with NFPROTO_UNSPEC can be\nloaded by any protocol family through nft_compat. When such a\nmatch/target sets .hooks to restrict which hooks it may run on, the\nbitmask uses NF_INET_* constants. This is only correct for families\nwhose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge\nall share the same five hooks (PRE_ROUTING ... POST_ROUTING).\n\nARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different\nsemantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks\nvalidation silently passes for the wrong reasons, allowing matches to\nrun on ARP chains where the hook assumptions (e.g. state-\u0026gt;in being\nset on input hooks) do not hold. This leads to NULL pointer\ndereferences; xt_devgroup is one concrete example:\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI\n KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]\n RIP: 0010:devgroup_mt+0xff/0x350\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nft_match_eval (net/netfilter/nft_compat.c:407)\n nft_do_chain (net/netfilter/nf_tables_core.c:285)\n nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61)\n nf_hook_slow (net/netfilter/core.c:623)\n arp_xmit (net/ipv4/arp.c:666)\n \u0026lt;/TASK\u0026gt;\n Kernel panic - not syncing: Fatal exception in interrupt\n\nFix it by restricting arptables to NFPROTO_ARP extensions only.\nNote that arptables-legacy only supports:\n\n- arpt_CLASSIFY\n- arpt_mangle\n- arpt_MARK\n\nthat provide explicit NFPROTO_ARP match/target declarations.(CVE-2026-31424)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ctxfi: Limit PTP to a single page\n\nCommit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256\nplayback streams, but the additional pages are not used by the card\ncorrectly. The CT20K2 hardware already has multiple VMEM_PTPAL\nregisters, but using them separately would require refactoring the\nentire virtual memory allocation logic.\n\nct_vm_map() always uses PTEs in vm-\u0026gt;ptp[0].area regardless of\nCT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When\naggregate memory allocations exceed this limit, ct_vm_map() tries to\naccess beyond the allocated space and causes a page fault:\n\n BUG: unable to handle page fault for address: ffffd4ae8a10a000\n Oops: Oops: 0002 [#1] SMP PTI\n RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi]\n Call Trace:\n atc_pcm_playback_prepare+0x225/0x3b0\n ct_pcm_playback_prepare+0x38/0x60\n snd_pcm_do_prepare+0x2f/0x50\n snd_pcm_action_single+0x36/0x90\n snd_pcm_action_nonatomic+0xbf/0xd0\n snd_pcm_ioctl+0x28/0x40\n __x64_sys_ioctl+0x97/0xe0\n do_syscall_64+0x81/0x610\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nRevert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count\nremain unchanged.(CVE-2026-31602)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: flowlabel: defer exclusive option free until RCU teardown\n\n`ip6fl_seq_show()` walks the global flowlabel hash under the seq-file\nRCU read-side lock and prints `fl-\u0026gt;opt-\u0026gt;opt_nflen` when an option block\nis present.\n\nExclusive flowlabels currently free `fl-\u0026gt;opt` as soon as `fl-\u0026gt;users`\ndrops to zero in `fl_release()`. However, the surrounding\n`struct ip6_flowlabel` remains visible in the global hash table until\nlater garbage collection removes it and `fl_free_rcu()` finally tears it\ndown.\n\nA concurrent `/proc/net/ip6_flowlabel` reader can therefore race that\nearly `kfree()` and dereference freed option state, triggering a crash\nin `ip6fl_seq_show()`.\n\nFix this by keeping `fl-\u0026gt;opt` alive until `fl_free_rcu()`. That matches\nthe lifetime already required for the enclosing flowlabel while readers\ncan still reach it under RCU.(CVE-2026-31680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86: Fix potential bad container_of in intel_pmu_hw_config\n\nAuto counter reload may have a group of events with software events\npresent within it. The software event PMU isn\u0026apos;t the x86_hybrid_pmu and\na container_of operation in intel_pmu_set_acr_caused_constr (via the\nhybrid helper) could cause out of bound memory reads. Avoid this by\nguarding the call to intel_pmu_set_acr_caused_constr with an\nis_x86_event check.(CVE-2026-31782)",
"id": "OESA-2026-2232",
"modified": "2026-08-06T11:11:12Z",
"published": "2026-05-09T11:11:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23442"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31407"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31418"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31420"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31423"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31424"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31602"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31680"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31782"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-71089",
"CVE-2026-23442",
"CVE-2026-31407",
"CVE-2026-31418",
"CVE-2026-31420",
"CVE-2026-31423",
"CVE-2026-31424",
"CVE-2026-31602",
"CVE-2026-31680",
"CVE-2026-31782"
]
}
OPENSUSE-SU-2026:20287-1
Vulnerability from csaf_opensuse - Published: 2026-02-27 13:03 - Updated: 2026-09-17 17:27RHSA-2026:21556
Vulnerability from csaf_opensuse - Published: 2026-05-28 00:00 - Updated: 2026-09-16 18:19Sightings
| 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.