Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-40233 (GCVE-0-2025-40233)
Vulnerability from cvelistv5 – Published: 2025-12-04 15:31 – Updated: 2026-08-05 12:08| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
53069d4e76954e2e63c1b3c501051c6fbcf7298c , < 93166bc53c0e3587058327a4121daea34b4fecd5
(git)
Affected: 53069d4e76954e2e63c1b3c501051c6fbcf7298c , < a7ee72286efba1d407c6f15a0528e43593fb7007 (git) Affected: 53069d4e76954e2e63c1b3c501051c6fbcf7298c , < 93b1ab422f1966b71561158e1aedce4ec100f357 (git) Affected: 53069d4e76954e2e63c1b3c501051c6fbcf7298c , < e92af7737a94a729225d2a5d180eaaa77fe0bbc1 (git) Affected: 53069d4e76954e2e63c1b3c501051c6fbcf7298c , < aa6a21409dd6221bb268b56bb410e031c632ff9a (git) Affected: 53069d4e76954e2e63c1b3c501051c6fbcf7298c , < bb69928ed578f881e68d26aaf1a8f6e7faab3b44 (git) Affected: 53069d4e76954e2e63c1b3c501051c6fbcf7298c , < a21750df2f6169af6e039a3bb4893d6c9564e48d (git) Affected: 53069d4e76954e2e63c1b3c501051c6fbcf7298c , < 78a63493f8e352296dbc7cb7b3f4973105e8679e (git) |
guessed | |
| Linux | Linux |
Affected:
3.0
Unaffected: 0 , < 3.0 (semver) Unaffected: 5.4.301 , ≤ 5.4.* (semver) Unaffected: 5.10.246 , ≤ 5.10.* (semver) Unaffected: 5.15.196 , ≤ 5.15.* (semver) Unaffected: 6.1.158 , ≤ 6.1.* (semver) Unaffected: 6.6.115 , ≤ 6.6.* (semver) Unaffected: 6.12.56 , ≤ 6.12.* (semver) Unaffected: 6.17.6 , ≤ 6.17.* (semver) Unaffected: 6.18 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/ocfs2/move_extents.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "93166bc53c0e3587058327a4121daea34b4fecd5",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "a7ee72286efba1d407c6f15a0528e43593fb7007",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "93b1ab422f1966b71561158e1aedce4ec100f357",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "e92af7737a94a729225d2a5d180eaaa77fe0bbc1",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "aa6a21409dd6221bb268b56bb410e031c632ff9a",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "bb69928ed578f881e68d26aaf1a8f6e7faab3b44",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "a21750df2f6169af6e039a3bb4893d6c9564e48d",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "78a63493f8e352296dbc7cb7b3f4973105e8679e",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/ocfs2/move_extents.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.0"
},
{
"lessThan": "3.0",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.301",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.246",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.196",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.158",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.115",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.56",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.301",
"versionStartIncluding": "3.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.246",
"versionStartIncluding": "3.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.196",
"versionStartIncluding": "3.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.158",
"versionStartIncluding": "3.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.115",
"versionStartIncluding": "3.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.56",
"versionStartIncluding": "3.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17.6",
"versionStartIncluding": "3.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18",
"versionStartIncluding": "3.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: clear extent cache after moving/defragmenting extents\n\nThe extent map cache can become stale when extents are moved or\ndefragmented, causing subsequent operations to see outdated extent flags. \nThis triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().\n\nThe problem occurs when:\n1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED\n2. ioctl(FITRIM) triggers ocfs2_move_extents()\n3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)\n4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent()\n which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)\n5. The extent map cache is not invalidated after the move\n6. Later write() operations read stale cached flags (0x2) but disk has\n updated flags (0x0), causing a mismatch\n7. BUG_ON(!(rec-\u003ee_flags \u0026 OCFS2_EXT_REFCOUNTED)) triggers\n\nFix by clearing the extent map cache after each extent move/defrag\noperation in __ocfs2_move_extents_range(). This ensures subsequent\noperations read fresh extent data from disk."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerability is reached through the OCFS2_IOC_MOVE_EXT ioctl and a subsequent write()/read() on a local file descriptor, requiring local system access. No remote protocol handler is involved.\nAC:L - The trigger is a deterministic, fully attacker-controlled sequence (copy_file_range \u2192 OCFS2_IOC_MOVE_EXT \u2192 write) with no race window, no memory-layout dependency, and no reliance on any condition outside the attacker\u0027s control; syzbot reproduced it reliably.\nPR:L - OCFS2_IOC_MOVE_EXT has no capability check whatsoever (unlike FITRIM in the same switch which requires CAP_SYS_ADMIN); any unprivileged local user holding a writable fd on a regular file of a mounted ocfs2 volume can drive the whole sequence.\nUI:N - The attacker performs every step on its own file descriptor with no action by any other user; the ocfs2 mount is a pre-existing property of the deployment, not an action the attacker must induce.\nS:U - The corruption and crash are confined to the kernel and the filesystem\u0027s own on-disk data within the same security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - The stale extent-map entry retains the old physical cluster, which is freed to the global bitmap by the truncate-log flush at the end of the move, so later reads (O_DIRECT or buffered after cache eviction) resolve through the stale mapping and return the contents of clusters the allocator has since handed to other users\u0027 or root-owned files.\nI:H - The same stale cpos\u2192old_phys mapping is used for writes and writeback, so attacker-controlled data lands on physical clusters now owned by a different file, giving arbitrary on-disk corruption of files the attacker has no write permission to.\nA:H - BUG_ON(!(rec-\u003ee_flags \u0026 OCFS2_EXT_REFCOUNTED)) at fs/ocfs2/refcounttree.c:2683 oopses the task while it holds inode_lock, ip_alloc_sem and the ocfs2 DLM inode lock, permanently wedging the filesystem and blocking other cluster nodes; with panic_on_oops it is a full system panic."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T12:08:43.055Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/93166bc53c0e3587058327a4121daea34b4fecd5"
},
{
"url": "https://git.kernel.org/stable/c/a7ee72286efba1d407c6f15a0528e43593fb7007"
},
{
"url": "https://git.kernel.org/stable/c/93b1ab422f1966b71561158e1aedce4ec100f357"
},
{
"url": "https://git.kernel.org/stable/c/e92af7737a94a729225d2a5d180eaaa77fe0bbc1"
},
{
"url": "https://git.kernel.org/stable/c/aa6a21409dd6221bb268b56bb410e031c632ff9a"
},
{
"url": "https://git.kernel.org/stable/c/bb69928ed578f881e68d26aaf1a8f6e7faab3b44"
},
{
"url": "https://git.kernel.org/stable/c/a21750df2f6169af6e039a3bb4893d6c9564e48d"
},
{
"url": "https://git.kernel.org/stable/c/78a63493f8e352296dbc7cb7b3f4973105e8679e"
}
],
"title": "ocfs2: clear extent cache after moving/defragmenting extents",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-40233",
"datePublished": "2025-12-04T15:31:23.891Z",
"dateReserved": "2025-04-16T07:20:57.180Z",
"dateUpdated": "2026-08-05T12:08:43.055Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-40233",
"date": "2026-10-29",
"epss": "0.00155",
"percentile": "0.04562"
},
"microsoft_vex": {
"current_release_date": "2025-12-09T01:39:10.000Z",
"cve": "CVE-2025-40233",
"id": "msrc_CVE-2025-40233",
"initial_release_date": "2025-12-02T00:00:00.000Z",
"product_status:known_not_affected": "1",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "ocfs2: clear extent cache after moving/defragmenting extents",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-40233.json",
"version": "3"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/ocfs2/move_extents.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "93166bc53c0e3587058327a4121daea34b4fecd5",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "a7ee72286efba1d407c6f15a0528e43593fb7007",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "93b1ab422f1966b71561158e1aedce4ec100f357",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "e92af7737a94a729225d2a5d180eaaa77fe0bbc1",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "aa6a21409dd6221bb268b56bb410e031c632ff9a",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "bb69928ed578f881e68d26aaf1a8f6e7faab3b44",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "a21750df2f6169af6e039a3bb4893d6c9564e48d",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "78a63493f8e352296dbc7cb7b3f4973105e8679e",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/ocfs2/move_extents.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.0"
},
{
"lessThan": "3.0",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.301",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.246",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.196",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.158",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.115",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.56",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: clear extent cache after moving/defragmenting extents\n\nThe extent map cache can become stale when extents are moved or\ndefragmented, causing subsequent operations to see outdated extent flags. \nThis triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().\n\nThe problem occurs when:\n1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED\n2. ioctl(FITRIM) triggers ocfs2_move_extents()\n3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)\n4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent()\n which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)\n5. The extent map cache is not invalidated after the move\n6. Later write() operations read stale cached flags (0x2) but disk has\n updated flags (0x0), causing a mismatch\n7. BUG_ON(!(rec-\u003ee_flags \u0026 OCFS2_EXT_REFCOUNTED)) triggers\n\nFix by clearing the extent map cache after each extent move/defrag\noperation in __ocfs2_move_extents_range(). This ensures subsequent\noperations read fresh extent data from disk."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nocfs2: limpiar la cach\u00e9 de extents despu\u00e9s de mover/desfragmentar extents\n\nLa cach\u00e9 del mapa de extents puede quedar obsoleta cuando los extents son movidos o desfragmentados, lo que provoca que las operaciones subsiguientes vean flags de extent desactualizados. Esto dispara un BUG_ON en ocfs2_refcount_cal_cow_clusters().\n\nEl problema ocurre cuando:\n1. copy_file_range() crea un extent con reflink con OCFS2_EXT_REFCOUNTED\n2. ioctl(FITRIM) dispara ocfs2_move_extents()\n3. __ocfs2_move_extents_range() lee y cachea el extent (flags=0x2)\n4. ocfs2_move_extent()/ocfs2_defrag_extent() llama a __ocfs2_move_extent() que borra el flag OCFS2_EXT_REFCOUNTED en disco (flags=0x0)\n5. La cach\u00e9 del mapa de extents no se invalida despu\u00e9s del movimiento\n6. Operaciones de write() posteriores leen flags cacheados obsoletos (0x2) pero el disco tiene flags actualizados (0x0), causando una inconsistencia\n7. Se dispara BUG_ON(!(rec-\u003ee_flags \u0026 OCFS2_EXT_REFCOUNTED))\n\nLa soluci\u00f3n es limpiar la cach\u00e9 del mapa de extents despu\u00e9s de cada operaci\u00f3n de movimiento/desfragmentaci\u00f3n de extents en __ocfs2_move_extents_range(). Esto asegura que las operaciones subsiguientes lean datos de extent frescos del disco."
}
],
"id": "CVE-2025-40233",
"lastModified": "2026-10-19T21:10:00.160",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2025-12-04T16:16:16.137",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/78a63493f8e352296dbc7cb7b3f4973105e8679e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/93166bc53c0e3587058327a4121daea34b4fecd5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/93b1ab422f1966b71561158e1aedce4ec100f357"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a21750df2f6169af6e039a3bb4893d6c9564e48d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a7ee72286efba1d407c6f15a0528e43593fb7007"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/aa6a21409dd6221bb268b56bb410e031c632ff9a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/bb69928ed578f881e68d26aaf1a8f6e7faab3b44"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e92af7737a94a729225d2a5d180eaaa77fe0bbc1"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
},
"redhat_vex": {
"aggregate_severity": "None",
"current_release_date": "2026-06-30T10:20:22+00:00",
"cve": "CVE-2025-40233",
"id": "CVE-2025-40233",
"initial_release_date": "2025-12-04T00:00:00+00:00",
"product_status:known_not_affected": "274",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: ocfs2: clear extent cache after moving/defragmenting extents",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-40233.json",
"version": "3"
}
}
}
CERTFR-2026-AVI-0545
Vulnerability from certfr_avis - Published: 2026-05-07 - Updated: 2026-05-07
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 14.04",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.10",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 16.04",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2024-36903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36903"
},
{
"name": "CVE-2025-71075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71075"
},
{
"name": "CVE-2025-40273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40273"
},
{
"name": "CVE-2025-39987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39987"
},
{
"name": "CVE-2025-71086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71086"
},
{
"name": "CVE-2026-23167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23167"
},
{
"name": "CVE-2025-21861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21861"
},
{
"name": "CVE-2025-71065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71065"
},
{
"name": "CVE-2025-68374",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68374"
},
{
"name": "CVE-2026-23098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23098"
},
{
"name": "CVE-2025-68286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68286"
},
{
"name": "CVE-2025-71094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71094"
},
{
"name": "CVE-2025-68788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68788"
},
{
"name": "CVE-2025-40055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40055"
},
{
"name": "CVE-2025-39876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39876"
},
{
"name": "CVE-2025-40314",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40314"
},
{
"name": "CVE-2025-40029",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40029"
},
{
"name": "CVE-2025-40306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40306"
},
{
"name": "CVE-2025-68778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68778"
},
{
"name": "CVE-2025-40048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40048"
},
{
"name": "CVE-2025-40254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40254"
},
{
"name": "CVE-2025-71064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71064"
},
{
"name": "CVE-2025-40219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40219"
},
{
"name": "CVE-2025-68200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68200"
},
{
"name": "CVE-2025-40043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40043"
},
{
"name": "CVE-2025-68725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68725"
},
{
"name": "CVE-2025-68176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68176"
},
{
"name": "CVE-2025-68741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68741"
},
{
"name": "CVE-2025-68204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68204"
},
{
"name": "CVE-2025-68795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68795"
},
{
"name": "CVE-2025-68349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68349"
},
{
"name": "CVE-2025-68380",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68380"
},
{
"name": "CVE-2026-23269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23269"
},
{
"name": "CVE-2025-39973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39973"
},
{
"name": "CVE-2025-68339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68339"
},
{
"name": "CVE-2025-39943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39943"
},
{
"name": "CVE-2025-39945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39945"
},
{
"name": "CVE-2023-53421",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53421"
},
{
"name": "CVE-2026-22992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22992"
},
{
"name": "CVE-2022-49465",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49465"
},
{
"name": "CVE-2025-39883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39883"
},
{
"name": "CVE-2025-71071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71071"
},
{
"name": "CVE-2025-71191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71191"
},
{
"name": "CVE-2025-68295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68295"
},
{
"name": "CVE-2025-68728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68728"
},
{
"name": "CVE-2025-68364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68364"
},
{
"name": "CVE-2025-71087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71087"
},
{
"name": "CVE-2025-68287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68287"
},
{
"name": "CVE-2025-40240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40240"
},
{
"name": "CVE-2025-71135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71135"
},
{
"name": "CVE-2025-40081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40081"
},
{
"name": "CVE-2025-68746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68746"
},
{
"name": "CVE-2024-58011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58011"
},
{
"name": "CVE-2025-68773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68773"
},
{
"name": "CVE-2025-71133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71133"
},
{
"name": "CVE-2025-40026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40026"
},
{
"name": "CVE-2025-40153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40153"
},
{
"name": "CVE-2026-23020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23020"
},
{
"name": "CVE-2025-68796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68796"
},
{
"name": "CVE-2025-40121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40121"
},
{
"name": "CVE-2025-40312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40312"
},
{
"name": "CVE-2025-40204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40204"
},
{
"name": "CVE-2025-68220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68220"
},
{
"name": "CVE-2025-40171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40171"
},
{
"name": "CVE-2025-68302",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68302"
},
{
"name": "CVE-2025-68238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68238"
},
{
"name": "CVE-2025-68804",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68804"
},
{
"name": "CVE-2025-68769",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68769"
},
{
"name": "CVE-2025-68794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68794"
},
{
"name": "CVE-2025-39911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39911"
},
{
"name": "CVE-2025-40125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40125"
},
{
"name": "CVE-2025-40309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40309"
},
{
"name": "CVE-2025-40349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40349"
},
{
"name": "CVE-2025-38408",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38408"
},
{
"name": "CVE-2025-71088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71088"
},
{
"name": "CVE-2025-40343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40343"
},
{
"name": "CVE-2026-23090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23090"
},
{
"name": "CVE-2025-40308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40308"
},
{
"name": "CVE-2025-40187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40187"
},
{
"name": "CVE-2025-40315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40315"
},
{
"name": "CVE-2025-39913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39913"
},
{
"name": "CVE-2026-23064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23064"
},
{
"name": "CVE-2025-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38591"
},
{
"name": "CVE-2025-68806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68806"
},
{
"name": "CVE-2025-40092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40092"
},
{
"name": "CVE-2025-71098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71098"
},
{
"name": "CVE-2025-71078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71078"
},
{
"name": "CVE-2025-39967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39967"
},
{
"name": "CVE-2025-71083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71083"
},
{
"name": "CVE-2026-23061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23061"
},
{
"name": "CVE-2025-40115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40115"
},
{
"name": "CVE-2025-68813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68813"
},
{
"name": "CVE-2026-23047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23047"
},
{
"name": "CVE-2025-22121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22121"
},
{
"name": "CVE-2025-68365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68365"
},
{
"name": "CVE-2025-68265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68265"
},
{
"name": "CVE-2026-23119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23119"
},
{
"name": "CVE-2025-71085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71085"
},
{
"name": "CVE-2026-23268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23268"
},
{
"name": "CVE-2025-68344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68344"
},
{
"name": "CVE-2025-71154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71154"
},
{
"name": "CVE-2025-68229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68229"
},
{
"name": "CVE-2025-68257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68257"
},
{
"name": "CVE-2025-39949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39949"
},
{
"name": "CVE-2026-31431",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31431"
},
{
"name": "CVE-2025-71084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71084"
},
{
"name": "CVE-2025-40173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40173"
},
{
"name": "CVE-2026-23049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23049"
},
{
"name": "CVE-2025-68321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68321"
},
{
"name": "CVE-2024-56538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56538"
},
{
"name": "CVE-2025-68347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68347"
},
{
"name": "CVE-2025-39923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39923"
},
{
"name": "CVE-2025-68770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68770"
},
{
"name": "CVE-2025-68814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68814"
},
{
"name": "CVE-2025-68780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68780"
},
{
"name": "CVE-2025-39953",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39953"
},
{
"name": "CVE-2025-71081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71081"
},
{
"name": "CVE-2026-23101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23101"
},
{
"name": "CVE-2026-23407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23407"
},
{
"name": "CVE-2026-23099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23099"
},
{
"name": "CVE-2025-40167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40167"
},
{
"name": "CVE-2025-39969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39969"
},
{
"name": "CVE-2025-71121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71121"
},
{
"name": "CVE-2025-40194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40194"
},
{
"name": "CVE-2025-38022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38022"
},
{
"name": "CVE-2025-40245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40245"
},
{
"name": "CVE-2023-53520",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53520"
},
{
"name": "CVE-2026-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23085"
},
{
"name": "CVE-2025-40360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40360"
},
{
"name": "CVE-2026-23209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23209"
},
{
"name": "CVE-2025-71136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71136"
},
{
"name": "CVE-2025-68354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68354"
},
{
"name": "CVE-2025-68801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68801"
},
{
"name": "CVE-2026-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23150"
},
{
"name": "CVE-2025-68258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68258"
},
{
"name": "CVE-2025-40001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40001"
},
{
"name": "CVE-2025-40035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40035"
},
{
"name": "CVE-2025-40322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40322"
},
{
"name": "CVE-2025-39988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39988"
},
{
"name": "CVE-2025-40313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40313"
},
{
"name": "CVE-2025-71138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71138"
},
{
"name": "CVE-2025-38584",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38584"
},
{
"name": "CVE-2025-40233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40233"
},
{
"name": "CVE-2025-40020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40020"
},
{
"name": "CVE-2025-40188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40188"
},
{
"name": "CVE-2025-40271",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40271"
},
{
"name": "CVE-2025-68291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68291"
},
{
"name": "CVE-2025-71122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71122"
},
{
"name": "CVE-2026-22991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22991"
},
{
"name": "CVE-2025-68763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68763"
},
{
"name": "CVE-2025-71144",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71144"
},
{
"name": "CVE-2025-68308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68308"
},
{
"name": "CVE-2026-23408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23408"
},
{
"name": "CVE-2025-38234",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38234"
},
{
"name": "CVE-2025-40252",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40252"
},
{
"name": "CVE-2025-40049",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40049"
},
{
"name": "CVE-2025-68255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68255"
},
{
"name": "CVE-2026-22980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22980"
},
{
"name": "CVE-2025-40277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40277"
},
{
"name": "CVE-2025-40070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40070"
},
{
"name": "CVE-2025-40106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40106"
},
{
"name": "CVE-2025-40272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40272"
},
{
"name": "CVE-2026-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23133"
},
{
"name": "CVE-2026-23406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23406"
},
{
"name": "CVE-2025-71093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71093"
},
{
"name": "CVE-2025-71102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71102"
},
{
"name": "CVE-2026-23170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23170"
},
{
"name": "CVE-2025-68759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68759"
},
{
"name": "CVE-2026-23019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23019"
},
{
"name": "CVE-2026-23273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23273"
},
{
"name": "CVE-2025-71188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71188"
},
{
"name": "CVE-2025-40345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40345"
},
{
"name": "CVE-2025-40205",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40205"
},
{
"name": "CVE-2026-23125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23125"
},
{
"name": "CVE-2025-38057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38057"
},
{
"name": "CVE-2025-68733",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68733"
},
{
"name": "CVE-2025-40269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40269"
},
{
"name": "CVE-2025-68335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68335"
},
{
"name": "CVE-2025-71079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71079"
},
{
"name": "CVE-2026-22997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22997"
},
{
"name": "CVE-2025-71153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71153"
},
{
"name": "CVE-2025-68330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68330"
},
{
"name": "CVE-2023-53662",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53662"
},
{
"name": "CVE-2025-71196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71196"
},
{
"name": "CVE-2025-40027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40027"
},
{
"name": "CVE-2025-39885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39885"
},
{
"name": "CVE-2025-68772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68772"
},
{
"name": "CVE-2024-57795",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57795"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2026-23078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23078"
},
{
"name": "CVE-2025-71143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71143"
},
{
"name": "CVE-2025-68785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68785"
},
{
"name": "CVE-2025-71130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71130"
},
{
"name": "CVE-2024-37354",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37354"
},
{
"name": "CVE-2025-68808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68808"
},
{
"name": "CVE-2025-68783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68783"
},
{
"name": "CVE-2025-39970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39970"
},
{
"name": "CVE-2025-71147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71147"
},
{
"name": "CVE-2025-68724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68724"
},
{
"name": "CVE-2025-39994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39994"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-23074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23074"
},
{
"name": "CVE-2025-71126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71126"
},
{
"name": "CVE-2025-68786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68786"
},
{
"name": "CVE-2025-71199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71199"
},
{
"name": "CVE-2025-68797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68797"
},
{
"name": "CVE-2024-49968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49968"
},
{
"name": "CVE-2025-40088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40088"
},
{
"name": "CVE-2025-40220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40220"
},
{
"name": "CVE-2025-40257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40257"
},
{
"name": "CVE-2025-68259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68259"
},
{
"name": "CVE-2025-71125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71125"
},
{
"name": "CVE-2025-22058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22058"
},
{
"name": "CVE-2025-71108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71108"
},
{
"name": "CVE-2025-71069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71069"
},
{
"name": "CVE-2025-68312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68312"
},
{
"name": "CVE-2025-68284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68284"
},
{
"name": "CVE-2025-68194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68194"
},
{
"name": "CVE-2025-40109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40109"
},
{
"name": "CVE-2025-40006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40006"
},
{
"name": "CVE-2026-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23083"
},
{
"name": "CVE-2025-68774",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68774"
},
{
"name": "CVE-2025-40263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40263"
},
{
"name": "CVE-2025-40011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40011"
},
{
"name": "CVE-2026-23108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23108"
},
{
"name": "CVE-2025-40085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40085"
},
{
"name": "CVE-2025-71180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71180"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2025-68244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68244"
},
{
"name": "CVE-2025-40231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40231"
},
{
"name": "CVE-2024-46830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46830"
},
{
"name": "CVE-2024-47666",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47666"
},
{
"name": "CVE-2025-40278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40278"
},
{
"name": "CVE-2025-71194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71194"
},
{
"name": "CVE-2025-40342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40342"
},
{
"name": "CVE-2026-22999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22999"
},
{
"name": "CVE-2025-71082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71082"
},
{
"name": "CVE-2025-68765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68765"
},
{
"name": "CVE-2026-23089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23089"
},
{
"name": "CVE-2025-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23143"
},
{
"name": "CVE-2025-71132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71132"
},
{
"name": "CVE-2026-23071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23071"
},
{
"name": "CVE-2026-23056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23056"
},
{
"name": "CVE-2025-71077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71077"
},
{
"name": "CVE-2024-36927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36927"
},
{
"name": "CVE-2025-40279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40279"
},
{
"name": "CVE-2025-68328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68328"
},
{
"name": "CVE-2025-71140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71140"
},
{
"name": "CVE-2025-22111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22111"
},
{
"name": "CVE-2026-23063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23063"
},
{
"name": "CVE-2026-23073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23073"
},
{
"name": "CVE-2025-71114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71114"
},
{
"name": "CVE-2026-23058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23058"
},
{
"name": "CVE-2025-71067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71067"
},
{
"name": "CVE-2025-68744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68744"
},
{
"name": "CVE-2025-71182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71182"
},
{
"name": "CVE-2026-23038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23038"
},
{
"name": "CVE-2025-40183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40183"
},
{
"name": "CVE-2025-71151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71151"
},
{
"name": "CVE-2026-22990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22990"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2025-39998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39998"
},
{
"name": "CVE-2025-68821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68821"
},
{
"name": "CVE-2026-23026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23026"
},
{
"name": "CVE-2025-40134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40134"
},
{
"name": "CVE-2026-23128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23128"
},
{
"name": "CVE-2025-68325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68325"
},
{
"name": "CVE-2025-71190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71190"
},
{
"name": "CVE-2025-39968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39968"
},
{
"name": "CVE-2025-71089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71089"
},
{
"name": "CVE-2025-68332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68332"
},
{
"name": "CVE-2025-39986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39986"
},
{
"name": "CVE-2025-71104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71104"
},
{
"name": "CVE-2026-22978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22978"
},
{
"name": "CVE-2025-40283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40283"
},
{
"name": "CVE-2025-39955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39955"
},
{
"name": "CVE-2025-40324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40324"
},
{
"name": "CVE-2025-68378",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68378"
},
{
"name": "CVE-2025-71141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71141"
},
{
"name": "CVE-2026-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23146"
},
{
"name": "CVE-2025-38129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38129"
},
{
"name": "CVE-2026-23037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23037"
},
{
"name": "CVE-2026-23410",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23410"
},
{
"name": "CVE-2025-71101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71101"
},
{
"name": "CVE-2025-40264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40264"
},
{
"name": "CVE-2026-23001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23001"
},
{
"name": "CVE-2025-68367",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68367"
},
{
"name": "CVE-2025-40078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40078"
},
{
"name": "CVE-2025-68820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68820"
},
{
"name": "CVE-2025-68756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68756"
},
{
"name": "CVE-2025-40321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40321"
},
{
"name": "CVE-2025-40116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40116"
},
{
"name": "CVE-2023-54207",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54207"
},
{
"name": "CVE-2025-68249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68249"
},
{
"name": "CVE-2025-68740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68740"
},
{
"name": "CVE-2025-39934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39934"
},
{
"name": "CVE-2025-40179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40179"
},
{
"name": "CVE-2025-68742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68742"
},
{
"name": "CVE-2025-40127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40127"
},
{
"name": "CVE-2025-40282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40282"
},
{
"name": "CVE-2025-39996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39996"
},
{
"name": "CVE-2025-40053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40053"
},
{
"name": "CVE-2025-39951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39951"
},
{
"name": "CVE-2025-40120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40120"
},
{
"name": "CVE-2025-68816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68816"
},
{
"name": "CVE-2025-68192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68192"
},
{
"name": "CVE-2025-68379",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68379"
},
{
"name": "CVE-2025-68256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68256"
},
{
"name": "CVE-2025-68777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68777"
},
{
"name": "CVE-2025-68254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68254"
},
{
"name": "CVE-2025-40243",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40243"
},
{
"name": "CVE-2025-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38556"
},
{
"name": "CVE-2025-40040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40040"
},
{
"name": "CVE-2026-22982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22982"
},
{
"name": "CVE-2025-71109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71109"
},
{
"name": "CVE-2025-71118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71118"
},
{
"name": "CVE-2025-68327",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68327"
},
{
"name": "CVE-2025-71150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71150"
},
{
"name": "CVE-2026-23091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23091"
},
{
"name": "CVE-2025-68241",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68241"
},
{
"name": "CVE-2025-40118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40118"
},
{
"name": "CVE-2025-40021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40021"
},
{
"name": "CVE-2026-23121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23121"
},
{
"name": "CVE-2025-68734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68734"
},
{
"name": "CVE-2025-68776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68776"
},
{
"name": "CVE-2025-71066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71066"
},
{
"name": "CVE-2025-68799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68799"
},
{
"name": "CVE-2025-68345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68345"
},
{
"name": "CVE-2025-40044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40044"
},
{
"name": "CVE-2025-71097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71097"
},
{
"name": "CVE-2025-40105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40105"
},
{
"name": "CVE-2025-68288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68288"
},
{
"name": "CVE-2025-40112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40112"
},
{
"name": "CVE-2025-71107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71107"
},
{
"name": "CVE-2025-40083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40083"
},
{
"name": "CVE-2025-71111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71111"
},
{
"name": "CVE-2026-23087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23087"
},
{
"name": "CVE-2025-39971",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39971"
},
{
"name": "CVE-2025-71185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71185"
},
{
"name": "CVE-2025-40154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40154"
},
{
"name": "CVE-2025-40331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40331"
},
{
"name": "CVE-2025-68811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68811"
},
{
"name": "CVE-2022-49635",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49635"
},
{
"name": "CVE-2026-23096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23096"
},
{
"name": "CVE-2025-68337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68337"
},
{
"name": "CVE-2026-23405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23405"
},
{
"name": "CVE-2025-71131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71131"
},
{
"name": "CVE-2025-40149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40149"
},
{
"name": "CVE-2026-23403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23403"
},
{
"name": "CVE-2025-40164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40164"
},
{
"name": "CVE-2026-23164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23164"
},
{
"name": "CVE-2025-71116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71116"
},
{
"name": "CVE-2026-23124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23124"
},
{
"name": "CVE-2025-68362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68362"
},
{
"name": "CVE-2025-68290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68290"
},
{
"name": "CVE-2025-40280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40280"
},
{
"name": "CVE-2025-71162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71162"
},
{
"name": "CVE-2026-23075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23075"
},
{
"name": "CVE-2026-23120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23120"
},
{
"name": "CVE-2025-68803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68803"
},
{
"name": "CVE-2025-68331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68331"
},
{
"name": "CVE-2025-40126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40126"
},
{
"name": "CVE-2025-39972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39972"
},
{
"name": "CVE-2026-23105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23105"
},
{
"name": "CVE-2026-22976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22976"
},
{
"name": "CVE-2025-68753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68753"
},
{
"name": "CVE-2025-68369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68369"
},
{
"name": "CVE-2025-68775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68775"
},
{
"name": "CVE-2025-71112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71112"
},
{
"name": "CVE-2025-22022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22022"
},
{
"name": "CVE-2025-40200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40200"
},
{
"name": "CVE-2025-38236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38236"
},
{
"name": "CVE-2025-68818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68818"
},
{
"name": "CVE-2025-40124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40124"
},
{
"name": "CVE-2025-39880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39880"
},
{
"name": "CVE-2025-40094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40094"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2024-41014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41014"
},
{
"name": "CVE-2025-71148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71148"
},
{
"name": "CVE-2025-68366",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68366"
},
{
"name": "CVE-2024-36347",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36347"
},
{
"name": "CVE-2025-68815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68815"
},
{
"name": "CVE-2025-40215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40215"
},
{
"name": "CVE-2026-23095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23095"
},
{
"name": "CVE-2025-40111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40111"
},
{
"name": "CVE-2025-68346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68346"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"name": "CVE-2025-40211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40211"
},
{
"name": "CVE-2025-40068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40068"
},
{
"name": "CVE-2025-40042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40042"
},
{
"name": "CVE-2025-71096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71096"
},
{
"name": "CVE-2025-71095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71095"
},
{
"name": "CVE-2025-71105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71105"
},
{
"name": "CVE-2025-68266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68266"
},
{
"name": "CVE-2025-68771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68771"
},
{
"name": "CVE-2025-68363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68363"
},
{
"name": "CVE-2025-40248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40248"
},
{
"name": "CVE-2026-23411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23411"
},
{
"name": "CVE-2026-22984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22984"
},
{
"name": "CVE-2025-68303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68303"
},
{
"name": "CVE-2025-40259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40259"
},
{
"name": "CVE-2025-68757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68757"
},
{
"name": "CVE-2025-71068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71068"
},
{
"name": "CVE-2026-23033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23033"
},
{
"name": "CVE-2026-23409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23409"
},
{
"name": "CVE-2026-22977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22977"
},
{
"name": "CVE-2026-23003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23003"
},
{
"name": "CVE-2025-39937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39937"
},
{
"name": "CVE-2025-68766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68766"
},
{
"name": "CVE-2026-23076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23076"
},
{
"name": "CVE-2025-40060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40060"
},
{
"name": "CVE-2025-68168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68168"
},
{
"name": "CVE-2025-71123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71123"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2025-68372",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68372"
},
{
"name": "CVE-2026-23404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23404"
},
{
"name": "CVE-2026-23112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23112"
},
{
"name": "CVE-2025-71137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71137"
},
{
"name": "CVE-2026-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23084"
},
{
"name": "CVE-2025-68301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68301"
},
{
"name": "CVE-2026-23011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23011"
},
{
"name": "CVE-2025-68217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68217"
},
{
"name": "CVE-2025-40178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40178"
},
{
"name": "CVE-2025-68289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68289"
},
{
"name": "CVE-2025-40363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40363"
},
{
"name": "CVE-2025-39869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39869"
},
{
"name": "CVE-2025-40253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40253"
},
{
"name": "CVE-2025-39985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39985"
},
{
"name": "CVE-2025-68245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68245"
},
{
"name": "CVE-2025-40317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40317"
},
{
"name": "CVE-2025-68809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68809"
},
{
"name": "CVE-2025-71120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71120"
},
{
"name": "CVE-2026-23060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23060"
},
{
"name": "CVE-2025-68282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68282"
},
{
"name": "CVE-2025-68817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68817"
},
{
"name": "CVE-2025-71119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71119"
},
{
"name": "CVE-2025-68787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68787"
},
{
"name": "CVE-2025-68782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68782"
},
{
"name": "CVE-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2025-68177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68177"
},
{
"name": "CVE-2025-68758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68758"
},
{
"name": "CVE-2025-68191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68191"
},
{
"name": "CVE-2025-71113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71113"
},
{
"name": "CVE-2025-71127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71127"
},
{
"name": "CVE-2026-22998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22998"
},
{
"name": "CVE-2025-68340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68340"
},
{
"name": "CVE-2025-40258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40258"
},
{
"name": "CVE-2025-40281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40281"
},
{
"name": "CVE-2025-68185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68185"
},
{
"name": "CVE-2025-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40304"
},
{
"name": "CVE-2025-40110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40110"
},
{
"name": "CVE-2026-23111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23111"
},
{
"name": "CVE-2025-39980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39980"
},
{
"name": "CVE-2025-40325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40325"
},
{
"name": "CVE-2025-68798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68798"
},
{
"name": "CVE-2025-68336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68336"
},
{
"name": "CVE-2025-68810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68810"
},
{
"name": "CVE-2025-40346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40346"
},
{
"name": "CVE-2026-23097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23097"
},
{
"name": "CVE-2025-40262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40262"
},
{
"name": "CVE-2025-68819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68819"
},
{
"name": "CVE-2026-23231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23231"
},
{
"name": "CVE-2025-40261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40261"
},
{
"name": "CVE-2025-71072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71072"
},
{
"name": "CVE-2025-40030",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40030"
},
{
"name": "CVE-2025-40244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40244"
},
{
"name": "CVE-2025-39995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39995"
},
{
"name": "CVE-2026-23021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23021"
},
{
"name": "CVE-2025-68732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68732"
},
{
"name": "CVE-2025-68285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68285"
},
{
"name": "CVE-2026-23093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23093"
},
{
"name": "CVE-2025-37849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37849"
},
{
"name": "CVE-2025-68371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68371"
},
{
"name": "CVE-2025-40275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40275"
},
{
"name": "CVE-2025-39907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39907"
},
{
"name": "CVE-2025-68211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68211"
},
{
"name": "CVE-2025-71091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71091"
},
{
"name": "CVE-2025-68227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68227"
},
{
"name": "CVE-2025-40140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40140"
},
{
"name": "CVE-2025-40223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40223"
},
{
"name": "CVE-2025-68263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68263"
},
{
"name": "CVE-2025-68800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68800"
},
{
"name": "CVE-2024-53114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53114"
},
{
"name": "CVE-2025-68261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68261"
},
{
"name": "CVE-2025-68755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68755"
},
{
"name": "CVE-2025-71149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71149"
},
{
"name": "CVE-2025-68767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68767"
},
{
"name": "CVE-2025-39873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39873"
},
{
"name": "CVE-2025-40319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40319"
},
{
"name": "CVE-2025-68727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68727"
},
{
"name": "CVE-2026-23080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23080"
},
{
"name": "CVE-2025-38248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38248"
},
{
"name": "CVE-2025-40351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40351"
},
{
"name": "CVE-2025-68264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68264"
},
{
"name": "CVE-2025-40087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40087"
},
{
"name": "CVE-2025-68764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68764"
}
],
"initial_release_date": "2026-05-07T00:00:00",
"last_revision_date": "2026-05-07T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0545",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-05-07T00: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": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2026-05-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8243-1",
"url": "https://ubuntu.com/security/notices/USN-8243-1"
},
{
"published_at": "2026-04-30",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8226-1",
"url": "https://ubuntu.com/security/notices/USN-8226-1"
},
{
"published_at": "2026-05-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8179-4",
"url": "https://ubuntu.com/security/notices/USN-8179-4"
},
{
"published_at": "2026-05-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8244-1",
"url": "https://ubuntu.com/security/notices/USN-8244-1"
},
{
"published_at": "2026-04-30",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8226-2",
"url": "https://ubuntu.com/security/notices/USN-8226-2"
}
]
}
CERTFR-2026-AVI-0602
Vulnerability from certfr_avis - Published: 2026-05-15 - Updated: 2026-05-15
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2025-40166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40166"
},
{
"name": "CVE-2025-71075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71075"
},
{
"name": "CVE-2025-40273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40273"
},
{
"name": "CVE-2025-39992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39992"
},
{
"name": "CVE-2024-50142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50142"
},
{
"name": "CVE-2025-39987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39987"
},
{
"name": "CVE-2025-71086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71086"
},
{
"name": "CVE-2025-39812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39812"
},
{
"name": "CVE-2026-23167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23167"
},
{
"name": "CVE-2025-40156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40156"
},
{
"name": "CVE-2025-71065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71065"
},
{
"name": "CVE-2025-68342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68342"
},
{
"name": "CVE-2025-68374",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68374"
},
{
"name": "CVE-2025-40137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40137"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2026-23098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23098"
},
{
"name": "CVE-2025-39808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39808"
},
{
"name": "CVE-2025-68286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68286"
},
{
"name": "CVE-2025-40057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40057"
},
{
"name": "CVE-2025-71094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71094"
},
{
"name": "CVE-2025-68788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68788"
},
{
"name": "CVE-2025-40055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40055"
},
{
"name": "CVE-2025-39876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39876"
},
{
"name": "CVE-2025-40314",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40314"
},
{
"name": "CVE-2025-40029",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40029"
},
{
"name": "CVE-2025-40037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40037"
},
{
"name": "CVE-2025-40306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40306"
},
{
"name": "CVE-2025-40008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40008"
},
{
"name": "CVE-2025-39947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39947"
},
{
"name": "CVE-2025-68778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68778"
},
{
"name": "CVE-2025-40048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40048"
},
{
"name": "CVE-2025-40254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40254"
},
{
"name": "CVE-2025-71064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71064"
},
{
"name": "CVE-2025-40219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40219"
},
{
"name": "CVE-2025-68200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68200"
},
{
"name": "CVE-2025-39902",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39902"
},
{
"name": "CVE-2025-40043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40043"
},
{
"name": "CVE-2025-68725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68725"
},
{
"name": "CVE-2025-68176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68176"
},
{
"name": "CVE-2025-68741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68741"
},
{
"name": "CVE-2025-68204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68204"
},
{
"name": "CVE-2025-68795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68795"
},
{
"name": "CVE-2025-68349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68349"
},
{
"name": "CVE-2025-39948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39948"
},
{
"name": "CVE-2025-39826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39826"
},
{
"name": "CVE-2025-68380",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68380"
},
{
"name": "CVE-2026-23269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23269"
},
{
"name": "CVE-2025-39973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39973"
},
{
"name": "CVE-2025-39881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39881"
},
{
"name": "CVE-2023-2640",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2640"
},
{
"name": "CVE-2025-68283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68283"
},
{
"name": "CVE-2025-68246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68246"
},
{
"name": "CVE-2025-68339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68339"
},
{
"name": "CVE-2025-40287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40287"
},
{
"name": "CVE-2025-39943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39943"
},
{
"name": "CVE-2025-39945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39945"
},
{
"name": "CVE-2023-53421",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53421"
},
{
"name": "CVE-2025-39883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39883"
},
{
"name": "CVE-2025-71071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71071"
},
{
"name": "CVE-2025-71191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71191"
},
{
"name": "CVE-2025-68295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68295"
},
{
"name": "CVE-2025-23129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23129"
},
{
"name": "CVE-2025-68728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68728"
},
{
"name": "CVE-2025-68364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68364"
},
{
"name": "CVE-2025-40100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40100"
},
{
"name": "CVE-2025-71087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71087"
},
{
"name": "CVE-2025-40285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40285"
},
{
"name": "CVE-2025-39827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39827"
},
{
"name": "CVE-2025-22106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22106"
},
{
"name": "CVE-2025-68287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68287"
},
{
"name": "CVE-2025-40240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40240"
},
{
"name": "CVE-2025-39828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39828"
},
{
"name": "CVE-2025-71135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71135"
},
{
"name": "CVE-2025-40081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40081"
},
{
"name": "CVE-2025-68746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68746"
},
{
"name": "CVE-2025-68773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68773"
},
{
"name": "CVE-2025-71133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71133"
},
{
"name": "CVE-2025-40026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40026"
},
{
"name": "CVE-2025-40153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40153"
},
{
"name": "CVE-2025-40103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40103"
},
{
"name": "CVE-2025-40294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40294"
},
{
"name": "CVE-2025-68796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68796"
},
{
"name": "CVE-2025-40016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40016"
},
{
"name": "CVE-2025-40121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40121"
},
{
"name": "CVE-2025-40312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40312"
},
{
"name": "CVE-2025-40204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40204"
},
{
"name": "CVE-2025-68220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68220"
},
{
"name": "CVE-2025-22125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22125"
},
{
"name": "CVE-2025-40171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40171"
},
{
"name": "CVE-2025-68302",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68302"
},
{
"name": "CVE-2025-68238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68238"
},
{
"name": "CVE-2025-68297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68297"
},
{
"name": "CVE-2025-40221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40221"
},
{
"name": "CVE-2025-68804",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68804"
},
{
"name": "CVE-2025-68769",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68769"
},
{
"name": "CVE-2025-39811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39811"
},
{
"name": "CVE-2025-68794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68794"
},
{
"name": "CVE-2025-40056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40056"
},
{
"name": "CVE-2025-39911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39911"
},
{
"name": "CVE-2025-40125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40125"
},
{
"name": "CVE-2025-40350",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40350"
},
{
"name": "CVE-2025-40309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40309"
},
{
"name": "CVE-2025-40349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40349"
},
{
"name": "CVE-2025-40052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40052"
},
{
"name": "CVE-2025-38408",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38408"
},
{
"name": "CVE-2025-71088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71088"
},
{
"name": "CVE-2025-40343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40343"
},
{
"name": "CVE-2025-68173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68173"
},
{
"name": "CVE-2026-23090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23090"
},
{
"name": "CVE-2025-22103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22103"
},
{
"name": "CVE-2025-68307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68307"
},
{
"name": "CVE-2025-40308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40308"
},
{
"name": "CVE-2025-40187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40187"
},
{
"name": "CVE-2025-40315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40315"
},
{
"name": "CVE-2025-37860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37860"
},
{
"name": "CVE-2025-39913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39913"
},
{
"name": "CVE-2025-68231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68231"
},
{
"name": "CVE-2025-39950",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39950"
},
{
"name": "CVE-2026-23064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23064"
},
{
"name": "CVE-2025-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38591"
},
{
"name": "CVE-2025-68806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68806"
},
{
"name": "CVE-2025-40092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40092"
},
{
"name": "CVE-2025-71098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71098"
},
{
"name": "CVE-2025-40251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40251"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2025-71078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71078"
},
{
"name": "CVE-2025-39967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39967"
},
{
"name": "CVE-2025-68184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68184"
},
{
"name": "CVE-2025-40107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40107"
},
{
"name": "CVE-2025-71083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71083"
},
{
"name": "CVE-2026-23061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23061"
},
{
"name": "CVE-2025-40115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40115"
},
{
"name": "CVE-2025-68813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68813"
},
{
"name": "CVE-2025-22121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22121"
},
{
"name": "CVE-2025-68365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68365"
},
{
"name": "CVE-2025-68265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68265"
},
{
"name": "CVE-2026-23119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23119"
},
{
"name": "CVE-2025-71085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71085"
},
{
"name": "CVE-2026-23268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23268"
},
{
"name": "CVE-2025-39920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39920"
},
{
"name": "CVE-2025-40058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40058"
},
{
"name": "CVE-2025-68344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68344"
},
{
"name": "CVE-2025-40347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40347"
},
{
"name": "CVE-2025-71154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71154"
},
{
"name": "CVE-2022-49046",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49046"
},
{
"name": "CVE-2025-40198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40198"
},
{
"name": "CVE-2025-39942",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39942"
},
{
"name": "CVE-2025-68310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68310"
},
{
"name": "CVE-2025-68179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68179"
},
{
"name": "CVE-2025-68229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68229"
},
{
"name": "CVE-2025-68257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68257"
},
{
"name": "CVE-2025-39929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39929"
},
{
"name": "CVE-2025-39949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39949"
},
{
"name": "CVE-2024-46816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46816"
},
{
"name": "CVE-2025-71084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71084"
},
{
"name": "CVE-2025-40173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40173"
},
{
"name": "CVE-2026-23049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23049"
},
{
"name": "CVE-2025-68321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68321"
},
{
"name": "CVE-2025-68347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68347"
},
{
"name": "CVE-2025-40010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40010"
},
{
"name": "CVE-2025-39944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39944"
},
{
"name": "CVE-2025-39923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39923"
},
{
"name": "CVE-2025-68235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68235"
},
{
"name": "CVE-2025-68770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68770"
},
{
"name": "CVE-2025-39866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39866"
},
{
"name": "CVE-2025-39843",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39843"
},
{
"name": "CVE-2025-40202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40202"
},
{
"name": "CVE-2025-40311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40311"
},
{
"name": "CVE-2025-68814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68814"
},
{
"name": "CVE-2025-40237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40237"
},
{
"name": "CVE-2025-68780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68780"
},
{
"name": "CVE-2025-39953",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39953"
},
{
"name": "CVE-2025-71081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71081"
},
{
"name": "CVE-2026-23101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23101"
},
{
"name": "CVE-2026-23407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23407"
},
{
"name": "CVE-2026-23099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23099"
},
{
"name": "CVE-2025-40167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40167"
},
{
"name": "CVE-2025-38105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38105"
},
{
"name": "CVE-2025-39969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39969"
},
{
"name": "CVE-2025-71121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71121"
},
{
"name": "CVE-2025-40194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40194"
},
{
"name": "CVE-2025-40333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40333"
},
{
"name": "CVE-2025-38022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38022"
},
{
"name": "CVE-2025-40245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40245"
},
{
"name": "CVE-2025-39899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39899"
},
{
"name": "CVE-2025-71080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71080"
},
{
"name": "CVE-2023-53520",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53520"
},
{
"name": "CVE-2026-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23085"
},
{
"name": "CVE-2025-40360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40360"
},
{
"name": "CVE-2026-23209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23209"
},
{
"name": "CVE-2025-71136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71136"
},
{
"name": "CVE-2025-22105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22105"
},
{
"name": "CVE-2025-68354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68354"
},
{
"name": "CVE-2025-68801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68801"
},
{
"name": "CVE-2025-21833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21833"
},
{
"name": "CVE-2026-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23150"
},
{
"name": "CVE-2025-40104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40104"
},
{
"name": "CVE-2025-68258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68258"
},
{
"name": "CVE-2025-39853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39853"
},
{
"name": "CVE-2025-40001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40001"
},
{
"name": "CVE-2025-39871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39871"
},
{
"name": "CVE-2025-39857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39857"
},
{
"name": "CVE-2025-38709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38709"
},
{
"name": "CVE-2025-40035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40035"
},
{
"name": "CVE-2025-40322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40322"
},
{
"name": "CVE-2025-39988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39988"
},
{
"name": "CVE-2025-40313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40313"
},
{
"name": "CVE-2025-39865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39865"
},
{
"name": "CVE-2025-71138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71138"
},
{
"name": "CVE-2025-40233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40233"
},
{
"name": "CVE-2025-40172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40172"
},
{
"name": "CVE-2025-40020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40020"
},
{
"name": "CVE-2024-46777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46777"
},
{
"name": "CVE-2025-40188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40188"
},
{
"name": "CVE-2025-40271",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40271"
},
{
"name": "CVE-2025-68291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68291"
},
{
"name": "CVE-2025-39877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39877"
},
{
"name": "CVE-2025-71122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71122"
},
{
"name": "CVE-2025-38502",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38502"
},
{
"name": "CVE-2025-39886",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39886"
},
{
"name": "CVE-2025-68763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68763"
},
{
"name": "CVE-2025-71144",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71144"
},
{
"name": "CVE-2025-68308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68308"
},
{
"name": "CVE-2025-40242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40242"
},
{
"name": "CVE-2025-39838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39838"
},
{
"name": "CVE-2025-39823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39823"
},
{
"name": "CVE-2025-68198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68198"
},
{
"name": "CVE-2026-23408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23408"
},
{
"name": "CVE-2025-38234",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38234"
},
{
"name": "CVE-2025-39864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39864"
},
{
"name": "CVE-2025-40013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40013"
},
{
"name": "CVE-2025-68190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68190"
},
{
"name": "CVE-2025-40169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40169"
},
{
"name": "CVE-2025-39824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39824"
},
{
"name": "CVE-2025-40252",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40252"
},
{
"name": "CVE-2025-68218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68218"
},
{
"name": "CVE-2025-40049",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40049"
},
{
"name": "CVE-2025-68255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68255"
},
{
"name": "CVE-2025-68322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68322"
},
{
"name": "CVE-2025-39927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39927"
},
{
"name": "CVE-2025-40024",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40024"
},
{
"name": "CVE-2025-40238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40238"
},
{
"name": "CVE-2025-40277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40277"
},
{
"name": "CVE-2025-40070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40070"
},
{
"name": "CVE-2025-40106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40106"
},
{
"name": "CVE-2025-40272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40272"
},
{
"name": "CVE-2025-39842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39842"
},
{
"name": "CVE-2025-40047",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40047"
},
{
"name": "CVE-2026-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23133"
},
{
"name": "CVE-2026-23406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23406"
},
{
"name": "CVE-2025-71093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71093"
},
{
"name": "CVE-2025-71102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71102"
},
{
"name": "CVE-2026-23170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23170"
},
{
"name": "CVE-2025-68759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68759"
},
{
"name": "CVE-2026-23273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23273"
},
{
"name": "CVE-2025-71188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71188"
},
{
"name": "CVE-2025-39815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39815"
},
{
"name": "CVE-2025-40345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40345"
},
{
"name": "CVE-2025-40205",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40205"
},
{
"name": "CVE-2026-23125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23125"
},
{
"name": "CVE-2025-39849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39849"
},
{
"name": "CVE-2025-40033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40033"
},
{
"name": "CVE-2025-38057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38057"
},
{
"name": "CVE-2025-68733",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68733"
},
{
"name": "CVE-2025-39894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39894"
},
{
"name": "CVE-2025-39861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39861"
},
{
"name": "CVE-2025-40269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40269"
},
{
"name": "CVE-2025-68335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68335"
},
{
"name": "CVE-2025-71079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71079"
},
{
"name": "CVE-2025-39940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39940"
},
{
"name": "CVE-2026-22997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22997"
},
{
"name": "CVE-2025-71153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71153"
},
{
"name": "CVE-2025-39977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39977"
},
{
"name": "CVE-2025-68330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68330"
},
{
"name": "CVE-2023-53662",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53662"
},
{
"name": "CVE-2025-71196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71196"
},
{
"name": "CVE-2024-27388",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27388"
},
{
"name": "CVE-2025-40027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40027"
},
{
"name": "CVE-2025-39885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39885"
},
{
"name": "CVE-2025-68180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68180"
},
{
"name": "CVE-2025-68772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68772"
},
{
"name": "CVE-2025-68343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68343"
},
{
"name": "CVE-2024-57795",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57795"
},
{
"name": "CVE-2026-23078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23078"
},
{
"name": "CVE-2025-68201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68201"
},
{
"name": "CVE-2025-40289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40289"
},
{
"name": "CVE-2025-71143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71143"
},
{
"name": "CVE-2025-68785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68785"
},
{
"name": "CVE-2025-71130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71130"
},
{
"name": "CVE-2025-68808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68808"
},
{
"name": "CVE-2025-68223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68223"
},
{
"name": "CVE-2025-68783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68783"
},
{
"name": "CVE-2025-39970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39970"
},
{
"name": "CVE-2025-40292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40292"
},
{
"name": "CVE-2025-71147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71147"
},
{
"name": "CVE-2025-40032",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40032"
},
{
"name": "CVE-2025-39981",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39981"
},
{
"name": "CVE-2025-68724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68724"
},
{
"name": "CVE-2025-39994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39994"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-23074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23074"
},
{
"name": "CVE-2025-71126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71126"
},
{
"name": "CVE-2025-68786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68786"
},
{
"name": "CVE-2025-71199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71199"
},
{
"name": "CVE-2023-32629",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32629"
},
{
"name": "CVE-2025-68797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68797"
},
{
"name": "CVE-2025-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38627"
},
{
"name": "CVE-2025-40206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40206"
},
{
"name": "CVE-2025-40218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40218"
},
{
"name": "CVE-2025-40088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40088"
},
{
"name": "CVE-2025-40220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40220"
},
{
"name": "CVE-2025-39845",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39845"
},
{
"name": "CVE-2025-68237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68237"
},
{
"name": "CVE-2025-40257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40257"
},
{
"name": "CVE-2025-68259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68259"
},
{
"name": "CVE-2025-71125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71125"
},
{
"name": "CVE-2025-71108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71108"
},
{
"name": "CVE-2025-71069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71069"
},
{
"name": "CVE-2025-68312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68312"
},
{
"name": "CVE-2025-68284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68284"
},
{
"name": "CVE-2025-40062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40062"
},
{
"name": "CVE-2025-68194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68194"
},
{
"name": "CVE-2025-40067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40067"
},
{
"name": "CVE-2025-40109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40109"
},
{
"name": "CVE-2025-40101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40101"
},
{
"name": "CVE-2025-40006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40006"
},
{
"name": "CVE-2026-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23083"
},
{
"name": "CVE-2025-40038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40038"
},
{
"name": "CVE-2025-68183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68183"
},
{
"name": "CVE-2025-39805",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39805"
},
{
"name": "CVE-2025-68774",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68774"
},
{
"name": "CVE-2025-40263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40263"
},
{
"name": "CVE-2025-40353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40353"
},
{
"name": "CVE-2025-40011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40011"
},
{
"name": "CVE-2026-23108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23108"
},
{
"name": "CVE-2025-40085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40085"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2025-68244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68244"
},
{
"name": "CVE-2025-40231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40231"
},
{
"name": "CVE-2025-40278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40278"
},
{
"name": "CVE-2025-71194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71194"
},
{
"name": "CVE-2025-22113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22113"
},
{
"name": "CVE-2025-40176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40176"
},
{
"name": "CVE-2025-40342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40342"
},
{
"name": "CVE-2026-22999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22999"
},
{
"name": "CVE-2025-71082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71082"
},
{
"name": "CVE-2025-68222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68222"
},
{
"name": "CVE-2025-68765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68765"
},
{
"name": "CVE-2026-23089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23089"
},
{
"name": "CVE-2025-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23143"
},
{
"name": "CVE-2025-71132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71132"
},
{
"name": "CVE-2026-23071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23071"
},
{
"name": "CVE-2026-23056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23056"
},
{
"name": "CVE-2025-40193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40193"
},
{
"name": "CVE-2025-71077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71077"
},
{
"name": "CVE-2025-40279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40279"
},
{
"name": "CVE-2025-68328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68328"
},
{
"name": "CVE-2025-40201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40201"
},
{
"name": "CVE-2025-71140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71140"
},
{
"name": "CVE-2025-40084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40084"
},
{
"name": "CVE-2025-22111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22111"
},
{
"name": "CVE-2024-49938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49938"
},
{
"name": "CVE-2026-23063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23063"
},
{
"name": "CVE-2026-23073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23073"
},
{
"name": "CVE-2025-68311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68311"
},
{
"name": "CVE-2025-71114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71114"
},
{
"name": "CVE-2026-23058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23058"
},
{
"name": "CVE-2025-71067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71067"
},
{
"name": "CVE-2025-68744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68744"
},
{
"name": "CVE-2025-68320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68320"
},
{
"name": "CVE-2026-23038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23038"
},
{
"name": "CVE-2025-40341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40341"
},
{
"name": "CVE-2025-40183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40183"
},
{
"name": "CVE-2025-71151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71151"
},
{
"name": "CVE-2024-50008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50008"
},
{
"name": "CVE-2025-68172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68172"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2025-39998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39998"
},
{
"name": "CVE-2025-68821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68821"
},
{
"name": "CVE-2026-23026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23026"
},
{
"name": "CVE-2025-40134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40134"
},
{
"name": "CVE-2026-23128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23128"
},
{
"name": "CVE-2025-68325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68325"
},
{
"name": "CVE-2025-71190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71190"
},
{
"name": "CVE-2025-39968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39968"
},
{
"name": "CVE-2025-71089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71089"
},
{
"name": "CVE-2025-40358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40358"
},
{
"name": "CVE-2025-40165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40165"
},
{
"name": "CVE-2025-40328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40328"
},
{
"name": "CVE-2025-68332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68332"
},
{
"name": "CVE-2025-39986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39986"
},
{
"name": "CVE-2025-71104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71104"
},
{
"name": "CVE-2025-39901",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39901"
},
{
"name": "CVE-2025-40283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40283"
},
{
"name": "CVE-2025-39955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39955"
},
{
"name": "CVE-2025-40324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40324"
},
{
"name": "CVE-2025-68378",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68378"
},
{
"name": "CVE-2025-71141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71141"
},
{
"name": "CVE-2026-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23146"
},
{
"name": "CVE-2026-23037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23037"
},
{
"name": "CVE-2026-23410",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23410"
},
{
"name": "CVE-2025-40250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40250"
},
{
"name": "CVE-2025-71101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71101"
},
{
"name": "CVE-2025-40264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40264"
},
{
"name": "CVE-2026-23001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23001"
},
{
"name": "CVE-2025-68367",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68367"
},
{
"name": "CVE-2025-40226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40226"
},
{
"name": "CVE-2025-40078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40078"
},
{
"name": "CVE-2025-68820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68820"
},
{
"name": "CVE-2025-68756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68756"
},
{
"name": "CVE-2025-40321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40321"
},
{
"name": "CVE-2025-40116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40116"
},
{
"name": "CVE-2025-39895",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39895"
},
{
"name": "CVE-2023-54207",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54207"
},
{
"name": "CVE-2025-68249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68249"
},
{
"name": "CVE-2025-68740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68740"
},
{
"name": "CVE-2025-39934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39934"
},
{
"name": "CVE-2025-39978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39978"
},
{
"name": "CVE-2025-40179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40179"
},
{
"name": "CVE-2025-68742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68742"
},
{
"name": "CVE-2025-40127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40127"
},
{
"name": "CVE-2025-40282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40282"
},
{
"name": "CVE-2025-39996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39996"
},
{
"name": "CVE-2025-40053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40053"
},
{
"name": "CVE-2025-39951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39951"
},
{
"name": "CVE-2025-40120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40120"
},
{
"name": "CVE-2025-68816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68816"
},
{
"name": "CVE-2025-39914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39914"
},
{
"name": "CVE-2025-68192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68192"
},
{
"name": "CVE-2025-39697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39697"
},
{
"name": "CVE-2025-68379",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68379"
},
{
"name": "CVE-2025-68256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68256"
},
{
"name": "CVE-2025-68777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68777"
},
{
"name": "CVE-2025-68254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68254"
},
{
"name": "CVE-2025-39938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39938"
},
{
"name": "CVE-2025-40243",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40243"
},
{
"name": "CVE-2025-40196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40196"
},
{
"name": "CVE-2025-39982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39982"
},
{
"name": "CVE-2025-40129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40129"
},
{
"name": "CVE-2025-39965",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39965"
},
{
"name": "CVE-2025-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38556"
},
{
"name": "CVE-2025-68171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68171"
},
{
"name": "CVE-2025-39932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39932"
},
{
"name": "CVE-2025-40301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40301"
},
{
"name": "CVE-2025-39810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39810"
},
{
"name": "CVE-2025-71109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71109"
},
{
"name": "CVE-2025-40207",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40207"
},
{
"name": "CVE-2025-40095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40095"
},
{
"name": "CVE-2025-71118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71118"
},
{
"name": "CVE-2025-39860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39860"
},
{
"name": "CVE-2025-40286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40286"
},
{
"name": "CVE-2025-68327",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68327"
},
{
"name": "CVE-2025-40318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40318"
},
{
"name": "CVE-2025-71150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71150"
},
{
"name": "CVE-2025-40266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40266"
},
{
"name": "CVE-2026-23091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23091"
},
{
"name": "CVE-2025-68241",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68241"
},
{
"name": "CVE-2025-40118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40118"
},
{
"name": "CVE-2025-40021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40021"
},
{
"name": "CVE-2025-39839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39839"
},
{
"name": "CVE-2026-23121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23121"
},
{
"name": "CVE-2025-68734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68734"
},
{
"name": "CVE-2025-68776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68776"
},
{
"name": "CVE-2025-71066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71066"
},
{
"name": "CVE-2025-39848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39848"
},
{
"name": "CVE-2025-68799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68799"
},
{
"name": "CVE-2025-68345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68345"
},
{
"name": "CVE-2025-40044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40044"
},
{
"name": "CVE-2025-71097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71097"
},
{
"name": "CVE-2025-40105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40105"
},
{
"name": "CVE-2025-68288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68288"
},
{
"name": "CVE-2025-39916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39916"
},
{
"name": "CVE-2025-40112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40112"
},
{
"name": "CVE-2025-71107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71107"
},
{
"name": "CVE-2025-40079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40079"
},
{
"name": "CVE-2025-40310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40310"
},
{
"name": "CVE-2025-40083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40083"
},
{
"name": "CVE-2025-71111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71111"
},
{
"name": "CVE-2026-23087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23087"
},
{
"name": "CVE-2025-39971",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39971"
},
{
"name": "CVE-2025-71185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71185"
},
{
"name": "CVE-2025-40154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40154"
},
{
"name": "CVE-2025-40331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40331"
},
{
"name": "CVE-2025-68811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68811"
},
{
"name": "CVE-2026-23096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23096"
},
{
"name": "CVE-2025-68337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68337"
},
{
"name": "CVE-2025-40093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40093"
},
{
"name": "CVE-2026-23405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23405"
},
{
"name": "CVE-2025-39825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39825"
},
{
"name": "CVE-2025-71131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71131"
},
{
"name": "CVE-2025-40149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40149"
},
{
"name": "CVE-2026-23403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23403"
},
{
"name": "CVE-2025-40164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40164"
},
{
"name": "CVE-2025-39852",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39852"
},
{
"name": "CVE-2026-23164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23164"
},
{
"name": "CVE-2025-71116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71116"
},
{
"name": "CVE-2025-40235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40235"
},
{
"name": "CVE-2025-39991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39991"
},
{
"name": "CVE-2026-23124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23124"
},
{
"name": "CVE-2025-68208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68208"
},
{
"name": "CVE-2025-68362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68362"
},
{
"name": "CVE-2025-39806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39806"
},
{
"name": "CVE-2025-68290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68290"
},
{
"name": "CVE-2025-40280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40280"
},
{
"name": "CVE-2025-40099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40099"
},
{
"name": "CVE-2025-71162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71162"
},
{
"name": "CVE-2026-23075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23075"
},
{
"name": "CVE-2026-23120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23120"
},
{
"name": "CVE-2025-40031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40031"
},
{
"name": "CVE-2025-40180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40180"
},
{
"name": "CVE-2025-40293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40293"
},
{
"name": "CVE-2025-39851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39851"
},
{
"name": "CVE-2025-68331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68331"
},
{
"name": "CVE-2025-40126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40126"
},
{
"name": "CVE-2025-39972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39972"
},
{
"name": "CVE-2026-23105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23105"
},
{
"name": "CVE-2025-68305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68305"
},
{
"name": "CVE-2025-68214",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68214"
},
{
"name": "CVE-2025-40320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40320"
},
{
"name": "CVE-2025-39870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39870"
},
{
"name": "CVE-2025-68753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68753"
},
{
"name": "CVE-2025-68369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68369"
},
{
"name": "CVE-2025-39807",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39807"
},
{
"name": "CVE-2025-68775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68775"
},
{
"name": "CVE-2025-71112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71112"
},
{
"name": "CVE-2025-22022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22022"
},
{
"name": "CVE-2025-40192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40192"
},
{
"name": "CVE-2025-40200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40200"
},
{
"name": "CVE-2025-68818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68818"
},
{
"name": "CVE-2025-40124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40124"
},
{
"name": "CVE-2025-39880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39880"
},
{
"name": "CVE-2025-40094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40094"
},
{
"name": "CVE-2025-40160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40160"
},
{
"name": "CVE-2025-40284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40284"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2025-40077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40077"
},
{
"name": "CVE-2025-40071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40071"
},
{
"name": "CVE-2025-71148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71148"
},
{
"name": "CVE-2025-68366",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68366"
},
{
"name": "CVE-2025-40305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40305"
},
{
"name": "CVE-2025-40080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40080"
},
{
"name": "CVE-2025-39846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39846"
},
{
"name": "CVE-2024-36347",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36347"
},
{
"name": "CVE-2025-68815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68815"
},
{
"name": "CVE-2025-40307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40307"
},
{
"name": "CVE-2026-23095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23095"
},
{
"name": "CVE-2025-40111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40111"
},
{
"name": "CVE-2025-68346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68346"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"name": "CVE-2025-40211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40211"
},
{
"name": "CVE-2025-40068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40068"
},
{
"name": "CVE-2025-68315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68315"
},
{
"name": "CVE-2025-39850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39850"
},
{
"name": "CVE-2025-40042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40042"
},
{
"name": "CVE-2025-40155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40155"
},
{
"name": "CVE-2025-71096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71096"
},
{
"name": "CVE-2025-39844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39844"
},
{
"name": "CVE-2025-71095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71095"
},
{
"name": "CVE-2025-71105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71105"
},
{
"name": "CVE-2025-68266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68266"
},
{
"name": "CVE-2025-68771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68771"
},
{
"name": "CVE-2025-39961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39961"
},
{
"name": "CVE-2025-68363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68363"
},
{
"name": "CVE-2025-40248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40248"
},
{
"name": "CVE-2026-23411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23411"
},
{
"name": "CVE-2025-68303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68303"
},
{
"name": "CVE-2025-39863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39863"
},
{
"name": "CVE-2025-40259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40259"
},
{
"name": "CVE-2025-68757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68757"
},
{
"name": "CVE-2025-71068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71068"
},
{
"name": "CVE-2025-23130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23130"
},
{
"name": "CVE-2025-40329",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40329"
},
{
"name": "CVE-2025-39957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39957"
},
{
"name": "CVE-2026-23033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23033"
},
{
"name": "CVE-2025-39931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39931"
},
{
"name": "CVE-2026-23409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23409"
},
{
"name": "CVE-2026-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23145"
},
{
"name": "CVE-2026-23003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23003"
},
{
"name": "CVE-2025-39937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39937"
},
{
"name": "CVE-2025-68766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68766"
},
{
"name": "CVE-2025-39817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39817"
},
{
"name": "CVE-2026-23076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23076"
},
{
"name": "CVE-2025-40060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40060"
},
{
"name": "CVE-2025-39891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39891"
},
{
"name": "CVE-2025-40059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40059"
},
{
"name": "CVE-2025-68168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68168"
},
{
"name": "CVE-2025-71123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71123"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2025-68372",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68372"
},
{
"name": "CVE-2026-23404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23404"
},
{
"name": "CVE-2026-23112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23112"
},
{
"name": "CVE-2025-22124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22124"
},
{
"name": "CVE-2025-68313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68313"
},
{
"name": "CVE-2025-71137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71137"
},
{
"name": "CVE-2026-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23084"
},
{
"name": "CVE-2025-40123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40123"
},
{
"name": "CVE-2025-68301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68301"
},
{
"name": "CVE-2025-39854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39854"
},
{
"name": "CVE-2026-23011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23011"
},
{
"name": "CVE-2025-68217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68217"
},
{
"name": "CVE-2025-40178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40178"
},
{
"name": "CVE-2025-68289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68289"
},
{
"name": "CVE-2025-40363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40363"
},
{
"name": "CVE-2025-39869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39869"
},
{
"name": "CVE-2025-40253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40253"
},
{
"name": "CVE-2025-39985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39985"
},
{
"name": "CVE-2025-68245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68245"
},
{
"name": "CVE-2025-68213",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68213"
},
{
"name": "CVE-2025-39952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39952"
},
{
"name": "CVE-2025-40317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40317"
},
{
"name": "CVE-2025-68809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68809"
},
{
"name": "CVE-2025-68233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68233"
},
{
"name": "CVE-2025-71120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71120"
},
{
"name": "CVE-2026-23060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23060"
},
{
"name": "CVE-2025-68282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68282"
},
{
"name": "CVE-2025-68817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68817"
},
{
"name": "CVE-2025-71119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71119"
},
{
"name": "CVE-2025-68787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68787"
},
{
"name": "CVE-2025-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23133"
},
{
"name": "CVE-2025-68782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68782"
},
{
"name": "CVE-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2025-68177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68177"
},
{
"name": "CVE-2025-68758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68758"
},
{
"name": "CVE-2025-68191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68191"
},
{
"name": "CVE-2025-71113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71113"
},
{
"name": "CVE-2025-71127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71127"
},
{
"name": "CVE-2026-22998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22998"
},
{
"name": "CVE-2025-40141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40141"
},
{
"name": "CVE-2025-68340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68340"
},
{
"name": "CVE-2025-39678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39678"
},
{
"name": "CVE-2025-68219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68219"
},
{
"name": "CVE-2025-40288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40288"
},
{
"name": "CVE-2025-40258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40258"
},
{
"name": "CVE-2025-40281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40281"
},
{
"name": "CVE-2025-68185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68185"
},
{
"name": "CVE-2025-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40304"
},
{
"name": "CVE-2025-40110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40110"
},
{
"name": "CVE-2025-40268",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40268"
},
{
"name": "CVE-2026-23111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23111"
},
{
"name": "CVE-2025-39980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39980"
},
{
"name": "CVE-2025-40325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40325"
},
{
"name": "CVE-2025-40009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40009"
},
{
"name": "CVE-2025-68798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68798"
},
{
"name": "CVE-2025-68336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68336"
},
{
"name": "CVE-2025-40303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40303"
},
{
"name": "CVE-2025-68810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68810"
},
{
"name": "CVE-2025-68178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68178"
},
{
"name": "CVE-2025-40337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40337"
},
{
"name": "CVE-2025-40346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40346"
},
{
"name": "CVE-2025-40036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40036"
},
{
"name": "CVE-2026-23097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23097"
},
{
"name": "CVE-2025-39832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39832"
},
{
"name": "CVE-2025-40000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40000"
},
{
"name": "CVE-2025-40262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40262"
},
{
"name": "CVE-2025-39813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39813"
},
{
"name": "CVE-2025-68819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68819"
},
{
"name": "CVE-2026-23231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23231"
},
{
"name": "CVE-2025-40261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40261"
},
{
"name": "CVE-2025-38643",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38643"
},
{
"name": "CVE-2025-71072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71072"
},
{
"name": "CVE-2025-40030",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40030"
},
{
"name": "CVE-2025-40244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40244"
},
{
"name": "CVE-2025-39995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39995"
},
{
"name": "CVE-2025-39847",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39847"
},
{
"name": "CVE-2025-39819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39819"
},
{
"name": "CVE-2025-68732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68732"
},
{
"name": "CVE-2025-40323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40323"
},
{
"name": "CVE-2025-39835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39835"
},
{
"name": "CVE-2025-68285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68285"
},
{
"name": "CVE-2025-40096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40096"
},
{
"name": "CVE-2026-23093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23093"
},
{
"name": "CVE-2025-37849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37849"
},
{
"name": "CVE-2025-39841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39841"
},
{
"name": "CVE-2025-68371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68371"
},
{
"name": "CVE-2025-40275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40275"
},
{
"name": "CVE-2025-39907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39907"
},
{
"name": "CVE-2025-68211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68211"
},
{
"name": "CVE-2025-39829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39829"
},
{
"name": "CVE-2025-71091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71091"
},
{
"name": "CVE-2025-39909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39909"
},
{
"name": "CVE-2025-68227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68227"
},
{
"name": "CVE-2025-40339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40339"
},
{
"name": "CVE-2025-40140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40140"
},
{
"name": "CVE-2025-40223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40223"
},
{
"name": "CVE-2025-40061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40061"
},
{
"name": "CVE-2025-68263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68263"
},
{
"name": "CVE-2025-68800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68800"
},
{
"name": "CVE-2025-68261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68261"
},
{
"name": "CVE-2025-68755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68755"
},
{
"name": "CVE-2025-71149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71149"
},
{
"name": "CVE-2025-68767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68767"
},
{
"name": "CVE-2025-39873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39873"
},
{
"name": "CVE-2025-40159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40159"
},
{
"name": "CVE-2025-40319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40319"
},
{
"name": "CVE-2025-68727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68727"
},
{
"name": "CVE-2026-23080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23080"
},
{
"name": "CVE-2025-39836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39836"
},
{
"name": "CVE-2025-40051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40051"
},
{
"name": "CVE-2025-40351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40351"
},
{
"name": "CVE-2025-68264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68264"
},
{
"name": "CVE-2025-40087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40087"
},
{
"name": "CVE-2025-68764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68764"
}
],
"initial_release_date": "2026-05-15T00:00:00",
"last_revision_date": "2026-05-15T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0602",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-05-15T00: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": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2026-05-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8261-1",
"url": "https://ubuntu.com/security/notices/USN-8261-1"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8266-1",
"url": "https://ubuntu.com/security/notices/USN-8266-1"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8180-6",
"url": "https://ubuntu.com/security/notices/USN-8180-6"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8254-2",
"url": "https://ubuntu.com/security/notices/USN-8254-2"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8265-1",
"url": "https://ubuntu.com/security/notices/USN-8265-1"
},
{
"published_at": "2026-05-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8260-1",
"url": "https://ubuntu.com/security/notices/USN-8260-1"
},
{
"published_at": "2026-05-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8258-1",
"url": "https://ubuntu.com/security/notices/USN-8258-1"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8267-1",
"url": "https://ubuntu.com/security/notices/USN-8267-1"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8200-3",
"url": "https://ubuntu.com/security/notices/USN-8200-3"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8255-2",
"url": "https://ubuntu.com/security/notices/USN-8255-2"
}
]
}
FKIE_CVE-2025-40233
Vulnerability from fkie_nvd - Published: 2025-12-04 16:16 - Updated: 2026-10-19 21:10| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/ocfs2/move_extents.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "93166bc53c0e3587058327a4121daea34b4fecd5",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "a7ee72286efba1d407c6f15a0528e43593fb7007",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "93b1ab422f1966b71561158e1aedce4ec100f357",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "e92af7737a94a729225d2a5d180eaaa77fe0bbc1",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "aa6a21409dd6221bb268b56bb410e031c632ff9a",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "bb69928ed578f881e68d26aaf1a8f6e7faab3b44",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "a21750df2f6169af6e039a3bb4893d6c9564e48d",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
},
{
"lessThan": "78a63493f8e352296dbc7cb7b3f4973105e8679e",
"status": "affected",
"version": "53069d4e76954e2e63c1b3c501051c6fbcf7298c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/ocfs2/move_extents.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.0"
},
{
"lessThan": "3.0",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.301",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.246",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.196",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.158",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.115",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.56",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: clear extent cache after moving/defragmenting extents\n\nThe extent map cache can become stale when extents are moved or\ndefragmented, causing subsequent operations to see outdated extent flags. \nThis triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().\n\nThe problem occurs when:\n1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED\n2. ioctl(FITRIM) triggers ocfs2_move_extents()\n3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)\n4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent()\n which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)\n5. The extent map cache is not invalidated after the move\n6. Later write() operations read stale cached flags (0x2) but disk has\n updated flags (0x0), causing a mismatch\n7. BUG_ON(!(rec-\u003ee_flags \u0026 OCFS2_EXT_REFCOUNTED)) triggers\n\nFix by clearing the extent map cache after each extent move/defrag\noperation in __ocfs2_move_extents_range(). This ensures subsequent\noperations read fresh extent data from disk."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nocfs2: limpiar la cach\u00e9 de extents despu\u00e9s de mover/desfragmentar extents\n\nLa cach\u00e9 del mapa de extents puede quedar obsoleta cuando los extents son movidos o desfragmentados, lo que provoca que las operaciones subsiguientes vean flags de extent desactualizados. Esto dispara un BUG_ON en ocfs2_refcount_cal_cow_clusters().\n\nEl problema ocurre cuando:\n1. copy_file_range() crea un extent con reflink con OCFS2_EXT_REFCOUNTED\n2. ioctl(FITRIM) dispara ocfs2_move_extents()\n3. __ocfs2_move_extents_range() lee y cachea el extent (flags=0x2)\n4. ocfs2_move_extent()/ocfs2_defrag_extent() llama a __ocfs2_move_extent() que borra el flag OCFS2_EXT_REFCOUNTED en disco (flags=0x0)\n5. La cach\u00e9 del mapa de extents no se invalida despu\u00e9s del movimiento\n6. Operaciones de write() posteriores leen flags cacheados obsoletos (0x2) pero el disco tiene flags actualizados (0x0), causando una inconsistencia\n7. Se dispara BUG_ON(!(rec-\u003ee_flags \u0026 OCFS2_EXT_REFCOUNTED))\n\nLa soluci\u00f3n es limpiar la cach\u00e9 del mapa de extents despu\u00e9s de cada operaci\u00f3n de movimiento/desfragmentaci\u00f3n de extents en __ocfs2_move_extents_range(). Esto asegura que las operaciones subsiguientes lean datos de extent frescos del disco."
}
],
"id": "CVE-2025-40233",
"lastModified": "2026-10-19T21:10:00.160",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2025-12-04T16:16:16.137",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/78a63493f8e352296dbc7cb7b3f4973105e8679e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/93166bc53c0e3587058327a4121daea34b4fecd5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/93b1ab422f1966b71561158e1aedce4ec100f357"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a21750df2f6169af6e039a3bb4893d6c9564e48d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a7ee72286efba1d407c6f15a0528e43593fb7007"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/aa6a21409dd6221bb268b56bb410e031c632ff9a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/bb69928ed578f881e68d26aaf1a8f6e7faab3b44"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e92af7737a94a729225d2a5d180eaaa77fe0bbc1"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
GHSA-PMPF-32WW-GFMP
Vulnerability from github – Published: 2025-12-04 18:30 – Updated: 2026-07-30 06:32In the Linux kernel, the following vulnerability has been resolved:
ocfs2: clear extent cache after moving/defragmenting extents
The extent map cache can become stale when extents are moved or defragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().
The problem occurs when: 1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED 2. ioctl(FITRIM) triggers ocfs2_move_extents() 3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2) 4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0) 5. The extent map cache is not invalidated after the move 6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch 7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggers
Fix by clearing the extent map cache after each extent move/defrag operation in __ocfs2_move_extents_range(). This ensures subsequent operations read fresh extent data from disk.
{
"affected": [],
"aliases": [
"CVE-2025-40233"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-04T16:16:16Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: clear extent cache after moving/defragmenting extents\n\nThe extent map cache can become stale when extents are moved or\ndefragmented, causing subsequent operations to see outdated extent flags. \nThis triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().\n\nThe problem occurs when:\n1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED\n2. ioctl(FITRIM) triggers ocfs2_move_extents()\n3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)\n4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent()\n which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)\n5. The extent map cache is not invalidated after the move\n6. Later write() operations read stale cached flags (0x2) but disk has\n updated flags (0x0), causing a mismatch\n7. BUG_ON(!(rec-\u003ee_flags \u0026 OCFS2_EXT_REFCOUNTED)) triggers\n\nFix by clearing the extent map cache after each extent move/defrag\noperation in __ocfs2_move_extents_range(). This ensures subsequent\noperations read fresh extent data from disk.",
"id": "GHSA-pmpf-32ww-gfmp",
"modified": "2026-07-30T06:32:17Z",
"published": "2025-12-04T18:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40233"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78a63493f8e352296dbc7cb7b3f4973105e8679e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93166bc53c0e3587058327a4121daea34b4fecd5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93b1ab422f1966b71561158e1aedce4ec100f357"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a21750df2f6169af6e039a3bb4893d6c9564e48d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7ee72286efba1d407c6f15a0528e43593fb7007"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa6a21409dd6221bb268b56bb410e031c632ff9a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb69928ed578f881e68d26aaf1a8f6e7faab3b44"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e92af7737a94a729225d2a5d180eaaa77fe0bbc1"
}
],
"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-40233
Vulnerability from csaf_microsoft - Published: 2025-12-02 00:00 - Updated: 2025-12-09 01:39OESA-2026-4591 (CVE-2025-40233)
Vulnerability from osv_openeuler – Published: 2026-10-29 09:03 – Updated: 2026-10-29 09:03 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: clear extent cache after moving/defragmenting extents
The extent map cache can become stale when extents are moved or defragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().
The problem occurs when: 1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED 2. ioctl(FITRIM) triggers ocfs2_move_extents() 3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2) 4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0) 5. The extent map cache is not invalidated after the move 6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch 7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggers
Fix by clearing the extent map cache after each extent move/defrag operation in __ocfs2_move_extents_range(). This ensures subsequent operations read fresh extent data from disk.(CVE-2025-40233)
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: properly keep track of conduit reference
Problem description
DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense.
There are two distinct problems.
- The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch:
(unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind
we see these lines in the output diff which appear only with the patch applied:
kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)
- After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()).
Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it.
So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference.
Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.
As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself.
History and blame attribution
The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct.
We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---(CVE-2025-71152)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix out-of-bounds write in ocfs2_write_end_inline
KASAN reports a use-after-free write of 4086 bytes in ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF.
The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk id_count field to determine whether a write fits in inline data. On a corrupted filesystem, id_count can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer.
Call trace (crash path):
vfs_copy_file_range (fs/read_write.c:1634) do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949) ocfs2_write_end_inline (fs/ocfs2/aops.c:1915) memcpy_from_folio <-- KASAN: write OOB
So add id_count upper bound check in ocfs2_validate_inode_block() to alongside the existing i_size check to fix it.(CVE-2026-43075)
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Limit XDomain response copy to actual frame size
tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions.
Use the minimum of frame size and expected response size for the copy length.(CVE-2026-53146)
In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: update file PMD counter before folio_put()
__split_huge_pmd_locked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked().
Move the counter update before folio_put().(CVE-2026-53189)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: bnep: reject short frames before parsing
A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload.
Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads.
For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication.
Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)(CVE-2026-53253)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: validate skb length in MCC handlers
The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers.
Fix this by using skb_pull_data() to validate and access the required data before dereferencing it.
rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.(CVE-2026-53254)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack: destroy stale expectfn expectations on unregister
NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text.
When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port:
Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323]
Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless.
Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.(CVE-2026-53349)
In the Linux kernel, the following vulnerability has been resolved:
ntfs3: reject direct userspace writes to reserved $LX* xattrs
NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm().
Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload.
Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly.
[(CVE-2026-63833)
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count
rmi_f3a_initialize() takes the GPIO count from the device query register (f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127). rmi_f3a_map_gpios() then allocates gpio_key_map with min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f3a_attention() iterates the full gpio_count and dereferences gpio_key_map[i], and input->keycodemax is set to the full gpio_count while input->keycode points at the 6-entry allocation.
A device that reports gpio_count > 6 therefore causes an out-of-bounds read of gpio_key_map[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since input_default_getkeycode() and input_default_setkeycode() only bound the index against keycodemax.
Size the keymap for the full gpio_count. The mapping loop is unchanged: it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END) entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills) and are skipped when reporting.(CVE-2026-64277)
In the Linux kernel, the following vulnerability has been resolved:
HID: appleir: fix UAF on pending key_up_timer in remove()
appleir_remove() runs hid_hw_stop() before timer_delete_sync(). hid_hw_stop() synchronously unregisters the HID input device via hid_disconnect() -> hidinput_disconnect() -> input_unregister_device(), which drops the last reference and frees the underlying input_dev when no userspace handle holds it open.
key_up_tick() reads appleir->input_dev and calls input_report_key() / input_sync() on it. The timer is armed from appleir_raw_event() with a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a key was pressed shortly before the device is disconnected, the timer can fire after hid_hw_stop() has freed input_dev but before the teardown drains it.
A simple reorder is not sufficient. Putting the timer drain first still leaves a window where a USB URB completion (raw_event) running during hid_hw_stop() can call mod_timer() and re-arm the timer, which then fires after hidinput_disconnect() has freed input_dev. The same URB-completion window also lets raw_event() reach key_up(), key_down() and battery_flat() directly, all of which dereference appleir->input_dev.
Introduce a 'removing' flag on struct appleir, gated by the existing spinlock. appleir_remove() sets the flag under the lock and then shuts down the timer with timer_shutdown_sync(), which both drains any in-flight callback and permanently disables further mod_timer() calls. appleir_raw_event() and key_up_tick() bail out early if the flag is set, so no path can arm or run the timer, or dereference appleir->input_dev, after remove() has started tearing down.
The keyrepeat and flatbattery branches of appleir_raw_event() previously called into the input layer without holding the spinlock; take it now so the flag check is well-defined. This incidentally closes a pre-existing read-side race on appleir->current_key in the keyrepeat branch.
This bug is structurally a sibling of commit 4db2af929279 ("HID: appletb-kbd: fix UAF in inactivity-timer cleanup path") and has been present since the driver was introduced.(CVE-2026-64363)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: bound NTFS_DE view.data_off in UpdateRecordData{Root,Allocation}
In do_action()'s UpdateRecordDataRoot (fslog.c:3489) and
UpdateRecordDataAllocation (fslog.c:3697) cases, the memmove
destination is Add2Ptr(e, le16_to_cpu(e->view.data_off)),
where e->view.data_off comes from an on-disk NTFS_DE inside
an INDEX_ROOT or INDEX_BUFFER. Neither case validates
view.data_off + dlen against e->size; the existing
check_if_index_root / check_if_alloc_index helpers walk the
entry chain and validate the entry's offset, but not its
internal view fields.
The neighbouring read sites (e.g., fs/ntfs3/index.c when iterating view entries) check view.data_off + view.data_size <= e->size. Apply the same bound at the two memmove sites.
Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe instrumentation: with view.data_off forced to 0xFFFC, the memmove writes 32 bytes past the end of the NTFS_DE.
This is similar in shape to Pavitra Jha's 2026-05-02 patch "fs/ntfs3: prevent oob in case UpdateRecordDataRoot" (<(CVE-2026-64532)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket
smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release.
The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory:
WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set
Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free.
Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.(CVE-2026-64541)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btrtl: validate firmware patch bounds
rtlbt_parse_firmware() copies patch_length - 4 bytes before appending the firmware version. A malformed firmware patch shorter than the version field can make this subtraction underflow and turn the copy into an oversized read and write during Bluetooth setup.
The existing patch_offset + patch_length check can also wrap on 32-bit architectures. Validate the patch length and range without arithmetic overflow before allocating or copying the patch.(CVE-2026-68479)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set
When a USB audio endpoint requests full packet transfers via the fill_max descriptor flag, data_ep_set_params() promotes ep->curpacksize to ep->maxpacksize. However, maxsize is left at the original sample-rate derived value.
Since u->buffer_size is allocated as maxsize * packets, the resulting DMA buffer is far too small for the requested transfer length. When the USB host controller streams up to curpacksize bytes per packet, it writes past the end of the buffer via DMA, corrupting kernel heap memory.
Update maxsize to curpacksize when fill_max is set so that the allocated DMA buffer size matches the actual transfer request size.
changed to reassign maxsize only when ep->fill_max is set -- tiwai
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: HIDP: validate numbered report payloads
When hidp_get_raw_report() waits for a numbered report, hidp_process_data() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed.
KMSAN reports an uninitialized-value use in hidp_session_run(), with the value originating in __alloc_skb() through vhci_write(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added.
The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds.
Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload.(CVE-2026-74507)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: HIDP: reject frames without a transaction header
hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom.
KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one.
The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds.
Pull the transaction header with skb_pull_data() and discard frames that do not contain it.(CVE-2026-74508)
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: clear suppressed fib6 rule result
fib6_rule_suppress() drops a suppressed route with ip6_rt_put_flags(), but leaves res->rt6 pointing at the released rt6_info.
If no later rule supplies a replacement, fib6_rule_lookup() still sees res.rt6 and returns that stale dst to its caller. A suppressing rule can therefore leak a released route back to rt6_lookup(), and the next put hits rcuref_put_slowpath() from dst_release().
Clear res->rt6 when suppressing the route so suppressed lookups fall through to the null dst instead of reusing the released one.(CVE-2026-74581)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_route: fix fastmap use-after-free on filter
The route4 classifier maintains a 16-slot fastmap cache that stores raw struct route4_filter pointers indexed by (id, iif). The reader (route4_classify) populates this cache via route4_set_fastmap() for every classified packet that hits a filter. The writer (route4_delete, route4_change) clears the cache via route4_reset_fastmap() before RCU-deferred kfree of the filter.
This creates a UAF race: 1. Reader walks the RCU-protected bucket chain, finds filter f 2. Writer unlinks f, calls route4_reset_fastmap(), then tcf_queue_work() 3. Reader calls route4_set_fastmap() and writes f into the cache after the writer's reset, caching a pointer about to be freed 4. After the RCU grace period, kfree(f) executes 5. Next classified packet on the same (id, iif) tuple hits the stale fastmap entry and reads f->res from freed memory
Reproduced with an mdelay(100) accelerator in route4_set_fastmap() and a concurrent add/delete stress test (provided by both zdi and Santosh). Both triggered KASAN slab-use-after-free reports in the route4 fastmap paths.
Fix: Introduce a per-filter boolean dying flag to suppress stale fastmap republishing by in-flight readers.(CVE-2026-74583)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent in6_dev_get() from resurrecting inet6_dev
in6_dev_get() reads dev->ip6_ptr under RCU and then unconditionally increments its refcount. Device teardown can clear the pointer and drop the last reference between these operations. The increment then resurrects an object whose RCU free has already been queued, so callers can use it after it is freed.
Use refcount_inc_not_zero() and return NULL when the object has already reached zero. RCU keeps the memory accessible through the attempted reference acquisition, and a successful increment pins the object for the caller.
An independent run on the exact unpatched 6f5156d7a31a (v7.2-rc3) kernel reproduced the invalid reference acquisition as UID 1000:
refcount_t: addition on 0; use-after-free. ip6_mc_source+0xef4/0x17e0
It was followed by the corresponding reference underflow in ip6_mc_source(). The supplied trace from the same unpatched revision additionally shows the access after the RCU read-side section ends:
BUG: KASAN: slab-use-after-free in mutex_lock+0x76/0xe0 Write of size 8 at addr ffff888015b50240 by task poc/1219
Bug found and triaged by OpenAI Security Research and validated by Trail of Bits.(CVE-2026-74630)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_u32: skip hash tables in u32_bind_class()
u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode through the walker callback. u32_bind_class() unconditionally casts the passed fh to tc_u_knode and accesses &n->res, so when fh is actually a tc_u_hnode, which has no tcf_result member, this results in a slab-out-of-bounds read of res->classid in tc_cls_bind_class().
The issue can be reproduced with the following commands:
tc qdisc add dev lo root handle 1: hfsc
tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit
tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1
tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit
Fix this by skipping hash tables via the TC_U32_KEY(handle) check.(CVE-2026-74739)
In the Linux kernel, the following vulnerability has been resolved:
inet: frags: strip GSO state from fragments before reassembly
A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with.
After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough:
kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: <TASK> __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 </TASK> Kernel panic - not syncing: Fatal exception in interrupt
This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list") and by commit 9e4b7a99a03a ("net: gso: fix panic on frag_list with mixed head alloc types") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls.
An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 ("tun: Allow GSO using virtio_net_hdr"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward.
Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.(CVE-2026-80590)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: re-fetch eth header after route_shortcircuit()
Before route_shortcircuit(), the eth header pointer is cached from eth_hdr(skb).
Inside route_shortcircuit(), pskb_may_pull() can be called, which may reallocate skb->head.
In this case, returning to vxlan_xmit() leaves the cached eth pointer pointing to freed memory, leading to a use-after-free when dereferencing eth->h_dest.
Fix this by updating eth = eth_hdr(skb) after calling route_shortcircuit().(CVE-2026-80681)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: do not propagate one-packet flag to synced conns
Synced connections can be created before their destination exists. When the destination is later added, ip_vs_bind_dest() copies connection flags from the destination into cp->flags.
IP_VS_CONN_F_ONE_PACKET connections are not synced. If a synced connection inherits IP_VS_CONN_F_ONE_PACKET while it is already hashed, expiry can treat it as a one-packet connection and skip unlinking the existing conn_tab node, leaving stale hash nodes pointing at a freed struct ip_vs_conn.
Drop IP_VS_CONN_F_ONE_PACKET from destination flags when binding synced connections.(CVE-2026-80714)
In the Linux kernel, the following vulnerability has been resolved:
slip: fix use-after-free in sl_sync()
slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor.
priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop:
/* Snapshot list, allow later requests */
list_replace_init(&net_todo_list, &list);
__rtnl_unlock();
...
if (dev->priv_destructor)
dev->priv_destructor(dev); /* slip_devs[i] = NULL */
if (dev->needs_free_netdev)
free_netdev(dev);
...
/* Free network device */
kobject_put(&dev->dev.kobj);
So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device:
CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed / sl = netdev_priv(dev) if (sl->tty || sl->leased) / use-after-free */
BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506
CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712
Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564
Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860
Commit e58c19124189 ("slip: Fix use-after-free Read in slip_open") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it.
Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: the ---truncated---(CVE-2026-81001)
In the Linux kernel, the following vulnerability has been resolved:
xdp: fix zero-copy frame layout
xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page and advertises PAGE_SIZE as its frame size. It allows the copied frame to occupy the page tail needed by skb_shared_info and records zero headroom even when metadata separates the frame header from packet data. An AF_XDP zero-copy packet redirected through cpumap can therefore make the skb overlap skb_shared_info or place it beyond the allocated page.
Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result.
BUG: KASAN: slab-out-of-bounds in skb_gro_receive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skb_gro_receive (net/core/gro.c:174) udp_gro_receive (net/ipv4/udp_offload.c:812) inet_gro_receive (net/ipv4/af_inet.c:1539) dev_gro_receive (net/core/gro.c:515) gro_receive_skb (net/core/gro.c:633) cpu_map_kthread_run (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Kernel panic - not syncing: KASAN: panic_on_warn set ...(CVE-2026-81002)
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Force requesting ACS when tboot is enabled
Currently the conditions of requesting ACS in detect_intel_iommu() don't include tboot, leading to a possible misconfiguration with ACS disabled (e.g. due to user opts) while iommu is later forced on by tboot_force_iommu().
Fix it by checking tboot in detect_intel_iommu().(CVE-2026-89448)
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: Fix CT limit teardown use-after-free
Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state.
An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down.
Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists.
Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization.
The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace.(CVE-2026-89488)
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: Reject Read lists that exceed the page budget
Individual Read segment lengths are validated at decode time, but nothing prevents a requester from sending multiple segments whose cumulative length exceeds the rq_pages array budget. When one segment fills the page array exactly, the runtime guard in svc_rdma_build_read_segment() is bypassed because len reaches zero. A subsequent segment then accesses the NULL sentinel slot at rq_pages[rq_maxpages], resulting in a NULL pointer dereference during DMA mapping.
Accumulate pages across all Read segments and reject the message at decode time when the total would overflow the page budget.(CVE-2026-89528)
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: Reject inline replies that overflow the pull-up buffer
An RPC-over-RDMA client can request a reply, such as an NFS READ payload, without providing a Write list or a Reply chunk to carry it. When such a reply needs more scatter/gather entries than the device's Send Queue supports, svc_rdma_pull_up_needed() selects pull-up and svc_rdma_pull_up_reply_msg() linearizes the whole reply into sctxt->sc_xprt_buf. That buffer is only sc_max_req_size bytes, while the reply on this path is bounded only by the client's request, so svc_rdma_xb_linearize() copies past the end of the buffer and corrupts adjacent slab memory. The oversized length is then stored in sc_sges[0].length and posted, so the device also reads beyond the mapped region.
The SGE-exhaustion branch is the only pull-up path that can exceed the buffer: the threshold branch pulls up only replies smaller than RPCRDMA_PULLUP_THRESH, and replies that fit the device's SGE budget are sent directly without linearization. Make svc_rdma_pull_up_needed() report -E2BIG when the reply it would pull up cannot fit sc_max_req_size, and fail the request with ERR_CHUNK as RFC 8166 Section 4.5.3 directs rather than dropping the connection.
The helper no longer answers a simple yes/no question: it now reports pull-up, no pull-up, or -E2BIG for a reply too large to linearize. Rename svc_rdma_pull_up_needed() to svc_rdma_check_pull_up() so its name no longer implies a boolean predicate.(CVE-2026-89530)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: fix gssx_dec_option_array error path bugs
Four coupled defects in the gssx XDR option-array decoder make the error paths unsafe: a NULL deref in the caller, a refcount leak on the decoded group_info, and a latent use-after-free that the leak fix would otherwise expose.
gssx_dec_option_array() sets oa->count = 1 before allocating oa->data. If that allocation fails, -ENOMEM is returned with oa->count == 1 and oa->data == NULL. All other error paths jump to free_oa: which frees oa->data and NULLs it but also leaves oa->count == 1. The caller trusts the count:
gssp_accept_sec_context_upcall()
gssx_dec_accept_sec_context()
gssx_dec_option_array() /* fails, count=1 data=NULL */
data = res.options.data[0].value /* NULL deref */
Independently, free_creds: releases the partially decoded svc_cred with a bare kfree(creds). gssx_dec_linux_creds() installs a groups_alloc() result into creds->cr_group_info; that object is kvmalloc-backed and refcounted, and only put_group_info() reaches kvfree(). A plain kfree(creds) drops the wrapper and leaks the group_info allocation.
The natural fix for the leak is to call free_svc_cred(creds) before kfree(creds), but free_svc_cred() invokes put_group_info() on creds->cr_group_info unconditionally when non-NULL. The existing out_free_groups: path in gssx_dec_linux_creds() already called groups_free() on that pointer without clearing it, so once free_svc_cred() is wired in, the subsequent put_group_info() would touch freed memory.
Fix all four together:
- Move the oa->count = 1 assignment below the oa->data allocation so it is never set when oa->data is NULL.
- Reset oa->count to 0 at free_oa: so count and data stay coherent and the caller sees an empty option array.
- Call free_svc_cred(creds) before kfree(creds) at free_creds: so the refcounted cr_group_info is released. free_svc_cred() either NULL-guards each field explicitly (cr_group_info has an if() check) or delegates to a helper that is NULL-safe itself (kfree for the string fields, gss_mech_put() which guards with if(gm) at gss_mech_switch.c:342), so it is safe to call on a partially decoded svc_cred where only cr_uid/cr_gid/cr_group_info have been written and everything else is zero from kzalloc.
- In gssx_dec_linux_creds()'s out_free_groups: path, release cr_group_info with put_group_info() rather than groups_free() so the teardown matches free_svc_cred()'s refcount-aware path, and clear the pointer so a later free_svc_cred() on the same creds does not release it a second time.(CVE-2026-89544)
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: defer rq_argp and rq_resp free until after RCU grace period
svc_rqst_free() frees rqstp->rq_argp and rqstp->rq_resp synchronously via kfree(), but defers the rqstp struct free via kfree_rcu(). After svc_exit_thread() calls list_del_rcu() and svc_rqst_free(), there is a window where RCU readers that started before list_del_rcu() can still traverse the thread list and find the rqstp. These readers (e.g. nfsd_nl_rpc_status_get_dumpit()) dereference rqstp->rq_argp, which has already been freed — a use-after-free.
Fix this by moving the kfree of rq_argp and rq_resp into an explicit call_rcu() callback alongside the struct free. Resources not accessed by RCU readers (bvec, buffer pages, scratch folio, auth_data) remain synchronously freed.(CVE-2026-89545)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction
mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection.
Restore subflow_req->local_id from the cookie entry, as done for the other fields.(CVE-2026-89554)
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix UAF in check_new_map() on session freed during unlock
check_new_map() iterates mdsc->sessions[] and for each active session drops mdsc->mutex to perform per-session operations. The forced-close path (rank removed from map) correctly takes a reference on s via ceph_get_mds_session() before releasing mdsc->mutex, but three other paths do not:
Path A (address changed): mutex_unlock → mutex_lock(&s->s_mutex) Path B (reconnect): mutex_unlock → send_mds_reconnect(mdsc, s) Path C (active transition): mutex_unlock → mutex_lock(&s->s_mutex)
Without the extra reference, another thread can acquire mdsc->mutex during the unlock window, call __unregister_session() which drops the last reference on s, and free it. The original thread then accesses freed memory via s->s_mutex.
Fix by adding ceph_get_mds_session(s) before each mutex_unlock and ceph_put_mds_session(s) after the corresponding mutex_lock, matching the pattern already used in the forced-close path.
Race timeline (Path A):
Thread A (check_new_map) Thread B (another map update holds mdsc->mutex or session teardown) -------------------------- -------------------------- s = mdsc->sessions[i] (refcount == 1, held only by sessions[] array)
mutex_unlock(&mdsc->mutex) ---> acquires mdsc->mutex __unregister_session(mdsc, s) sessions[i] = NULL ceph_put_mds_session(s) refcount: 1 -> 0 kfree(s) <--- freed!
mutex_lock(&s->s_mutex) UAF on freed s->s_mutex(CVE-2026-89654)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Prevent lock owner use-after-free during client teardown
__destroy_client() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on cl_ownerstr_hashtbl. client_has_state() does not count a bare owner, so DESTROY_CLIENTID can reach __destroy_client() with such owners present.
__destroy_client() then walks the table, calling remove_blocked_locks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flc_owner. The per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently of client state. The two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks().
nfsd4_release_lockowner() holds a reference across the same call; __destroy_client() does not. Hold cl_lock across the walk, taking a reference and unhashing each owner, then drop it before remove_blocked_locks() and nfs4_put_stateowner(), which take blocked_locks_lock and cl_lock.(CVE-2026-89662)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE
The NFSv2 sattr decoder converts the wire useconds to nanoseconds in svcxdr_decode_sattr():
iap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC;
tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds value such as 4294968 wraps to tv_nsec == 704. The corruption therefore happens during decode, before any proc function can inspect the value, and a later range check on tv_nsec would see an in-range result and accept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply. NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return for a malformed time argument, and the check cannot move to the proc function the way the v3/v4 nsec range checks do.
Guard the raw useconds before the multiplication and reject values greater than 1000000. useconds == 1000000 is kept: it is the Sun convention for "set to the current server time", and the in-tree Linux NFSv2 client emits it in both the atime and the mtime field for a plain touch / utimes(file, NULL) (see encode_sattr() and xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000 would turn that common operation into a hard decode failure for both SETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap on ILP32, so the Sun convention value passes through safely. Only genuinely out-of-range values (> 1000000) are rejected. The atime and mtime guards are therefore symmetric.
The decoder only applied the Sun convention in the mtime block, which clears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a client puts 1000000 in the atime field but not in the mtime field, the atime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET set, so the bogus value reached the filesystem. Apply the convention in the atime block as well, clearing ATTR_ATIME_SET so the server uses its current time and ignores the value. Only ATTR_ATIME_SET is cleared there. The mtime block keeps its existing behavior, where 1000000 means "set both atime and mtime to now".
cel: various tweaks, addenda, and clean-ups
In the Linux kernel, the following vulnerability has been resolved:
nfsd: reject out-of-range nseconds in NFSv3 SETATTR and create ops
A client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD carrying an atime or mtime whose nseconds field is out of range. The value is well-formed on the wire and decodes cleanly into a valid uint32, but it is not a valid timespec64: tv_nsec must be less than NSEC_PER_SEC.
Nothing in the setattr path clamps it. notify_change() runs the time through timestamp_truncate(), which does not reduce tv_nsec below NSEC_PER_SEC when the filesystem supports nanosecond granularity (s_time_gran == 1), and the inode atime/mtime setters store it verbatim (only ctime is normalized, via inode_set_ctime_to_ts()). The un-normalized value then corrupts on-disk metadata: ext4's ext4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, which overflows the 32-bit extra field and clobbers the seconds-epoch bits, so the stored seconds (and thus the year) are wrong on read-back. XFS with bigtime mis-stores the timestamp for the same reason.
Validate the client-supplied atime/mtime in the proc handlers and return NFS3ERR_INVAL before anything is changed. RFC 1813 lists NFS3ERR_INVAL for SETATTR and describes it as the error for a value the server 'can not store ... in its own representation'; the client maps it to EINVAL.
Checking in the proc handlers, rather than in nfsd_setattr(), keeps the rejection in front of object creation. The create operations create the object before nfsd_create_setattr() runs, so a late failure would leave the new object behind and turn a non-idempotent request into a namespace change that reports failure. The check is therefore done up front, for the create operations before the object is created.
tv_nsec is a long, so the comparison casts it to unsigned long (the same width) rather than to u32, matching timespec64_valid(). A u32 cast would truncate on 64-bit; the unsigned long cast also rejects a value that became negative when an out-of-range u32 wire nseconds was assigned to a 32-bit long.
Only client-supplied times are checked: SET_TO_SERVER_TIME requests carry no client value. The sattrguard3 ctime is deliberately left alone: an out-of-range guard simply never matches the object's ctime and yields NFS3ERR_NOT_SYNC via the existing guardtime comparison, which is the protocol-correct outcome rather than rejecting the request.(CVE-2026-89666)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: initialize copy-notify stateid before publishing it
nfsd4_copy_notify() finished initializing the cpntf state after nfs4_alloc_init_cpntf_state() had already linked it into the s2s_cp_stateids IDR and the parent's sc_cp_list, with cs_count == 1 (the membership reference) and none held for the caller. A racing OFFLOAD_CANCEL (crafted cl_id == nn->s2s_cp_cl_id plus the guessable so_id) could reach manage_cpntf_state() and free the entry, turning the caller's subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid writes into use-after-free. The owning clientid was also only recorded after publication, so it could not gate an ownership check in that window.
Record cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state() before nfs4_init_cp_state() publishes the entry, and return it with an extra reference. The caller reads the stateid under that reference and drops it with nfs4_put_cpntf_state(); on a late error the laundromat reaps the entry.(CVE-2026-89669)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: gate nfs3 setacl by argp->mask
nfsd3_proc_setacl() calls set_posix_acl() unconditionally for both ACL_TYPE_ACCESS and ACL_TYPE_DEFAULT, passing argp->acl_access and argp->acl_default verbatim. The NFSv3 ACL decoder only populates those pointers when the corresponding mask bit is set:
nfs3svc_decode_setaclargs()
if (args->mask & NFS_ACL) decode into acl_access
if (args->mask & NFS_DFACL) decode into acl_default
/* otherwise the pointer stays NULL (pc_argzero) */
nfsd3_proc_setacl()
set_posix_acl(.., ACL_TYPE_ACCESS, argp->acl_access)
set_posix_acl(.., ACL_TYPE_DEFAULT, argp->acl_default)
set_posix_acl(idmap, dentry, type, NULL) is the VFS "remove this ACL type" operation. A NULL pointer that means "the client did not send this arm" is therefore indistinguishable from "the client asked to remove this ACL". A SETACL with mask=NFS_ACL silently drops the directory's default ACL; mask=0 drops both.
The sibling nfsd3_proc_getacl() already consults argp->mask before touching each arm; mirror that in setacl.
Fix by wrapping each set_posix_acl() call in the matching mask bit check and initializing error to 0 before inode_lock so that a request with neither bit set leaves the on-disk ACLs untouched and returns nfs_ok. The out_drop_lock path and the unconditional posix_acl_release() at out: are preserved; both NULL-tolerate the skipped arms.(CVE-2026-89671)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget
The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client:
- fh_len doesn't account for XDR padding on the file handle data
- uid and gid lengths use "8 + len" but xdr_encode_opaque() actually writes "4 + xdr_align_size(len)" bytes
- ds_len omits the flags and stats_collect_hint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch
The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client.
Fix this by breaking out every encoded field explicitly in the ds_len calculation, using xdr_align_size() for all variable-length opaque fields, and correcting the header constants.(CVE-2026-89674)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix UAF in async copy cancel and shutdown
An async copy could be freed or used after free while a teardown caller (OFFLOAD_CANCEL, nfsd4_shutdown_copy, nfsd4_cancel_copy_by_sb) raced the copy kthread:
-
find_async_copy() bumped copy->refcount but left the copy on clp->async_copies, so the reaper's cleanup_async_copy() could run release_copy_files() concurrently with a cancel/shutdown caller. Both put and NULL nf_src/nf_dst without a common lock, double-putting the nfsd_file and freeing it early.
-
nfsd4_do_async_copy() set NFSD4_COPY_F_STOPPED before its final uses of the copy (nfsd_update_cmtime_attr() on copy->nf_dst, nfsd4_send_cb_offload()). nfsd4_stop_copy() treats a set STOPPED bit as "kthread done, skip kthread_stop()", so a teardown caller ran release_copy_files() -- which puts and NULLs nf_dst -- while the kthread still dereferenced it (NULL/UAF).
-
copy->copy_task was never pinned. The one-shot kthread self-reaps on return, so kthread_stop()'s get_task_struct() could touch a freed task_struct.
-
co_cb is embedded in the copy, but nfsd4_send_cb_offload() held a reference only on the client, so a concurrent teardown could free the copy while the CB_OFFLOAD callback was in flight.
Fix the teardown lifetime as a whole:
-
find_async_copy() unlinks the copy (clear cp_clp, list_del_init) under async_lock; the cancel, shutdown, and sb-cancel paths drop the list-membership reference via nfs4_put_copy() after nfsd4_stop_copy(). Drop the now-redundant list_del fixup from cleanup_async_copy().
-
Because unlinking hides the copy from the reaper, its cleanup_async_copy() can no longer remove the copy's s2s_cp_stateids entry; the cancel/shutdown/sb-cancel paths now call nfs4_free_copy_state() themselves (while cp_clp is still valid) so the entry does not dangle at freed memory for the laundromat and manage_cpntf_state() to dereference.
-
Give the kthread its own reference, taken in nfsd4_copy() before wake_up_process() and dropped at the end of nfsd4_do_async_copy(); call wake_up_process() before list_add().
-
Pin the task_struct with get_task_struct() in nfsd4_copy(), released in nfs4_put_copy(), so kthread_stop() is safe whenever the kthread exits. Set NFSD4_COPY_F_STOPPED only in nfsd4_stop_copy(), which now always kthread_stop()s before release_copy_files(); completion is still reported via NFSD4_COPY_F_COMPLETED, so nfsd4_has_active_async_copies() is unaffected. Each teardown caller removes the copy from clp->async_copies first, so kthread_stop() runs exactly once.
-
Take a copy reference in nfsd4_send_cb_offload(), dropped in nfsd4_cb_offload_release(). The kthread still holds its own reference there, so the refcount_inc() cannot race the final free.
-
Read cp_clp with smp_load_acquire() to pair with the unordered set_bit()/clear_bit() writers (Documentation/atomic_bitops.rst).(CVE-2026-89675)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix nfsd_file leak on inter-server COPY setup failure
When nfsd4_setup_inter_ssc() fails, nfsd4_copy() returns nfserr_offload_denied directly, bypassing the out: label where release_copy_files() would drop the nf_dst reference taken by nfs4_preprocess_stateid_op(). Each failed inter-server COPY leaks one nfsd_file, pinning file/inode/dentry/vfsmount.
Fix by setting status and jumping to out: instead of returning directly.(CVE-2026-89680)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix clock domain mismatch in clients_still_reclaiming()
clients_still_reclaiming() computes a deadline from nn->boot_time (CLOCK_REALTIME, ~1.7 billion) but compares it against ktime_get_boottime_seconds() (CLOCK_BOOTTIME, seconds since boot). The comparison is always false — it would take ~54 years of uptime for BOOTTIME to exceed the REALTIME-derived deadline.
This means any client can hold the server in grace indefinitely by sending CLAIM_PREVIOUS OPEN requests, blocking all non-reclaim operations for all other clients.
Add boot_time_bt (CLOCK_BOOTTIME) alongside the existing boot_time and use it for the deadline computation. boot_time (CLOCK_REALTIME) is preserved for its cl_boot clientid-nonce role.(CVE-2026-89685)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref
When CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return success with fh_dentry and fh_export both NULL if fh_verify() returns nfserr_stale and putfh->no_verify is true. The NFSD4_FH_FOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserr_nofilehandle check -- it does not prevent subsequent ops from running with a NULL fh_dentry.
A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes check_if_stalefh_allowed() to set no_verify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fh_want_write() which dereferences fh_export->ex_path.mnt without calling fh_verify() first, causing a NULL pointer dereference in the nfsd kthread.
Fix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set and fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow) and ops with ALLOWED_WITHOUT_FH (which don't need a resolved filehandle) may proceed. All other ops receive nfserr_stale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERR_STALE returned at that point.(CVE-2026-89696)
In the Linux kernel, the following vulnerability has been resolved:
lockd, nfsd: RCU-protect nlmsvc_ops dispatch
nlmsvc_ops is published by nfsd_lockd_init() and cleared by nfsd_lockd_shutdown() with plain stores, while lockd dereferences it unguarded from dispatch sites in fs/lockd/svcsubs.c. The pointer targets nfsd's .rodata and the fopen/fclose callbacks live in nfsd's .text, so a stale load after rmmod nfsd results in either a NULL deref or a module-text use-after-free.
Declare nlmsvc_ops as __rcu, publish via rcu_assign_pointer(), clear via RCU_INIT_POINTER() + synchronize_rcu(). Add a struct module *owner field to nlmsvc_binding and pin the module across indirect calls with try_module_get/module_put. When the binding is torn down, fall back to fput() to avoid leaking struct file references.(CVE-2026-89709)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Initialize NVMe abort_work once at submission
qla_nvme_fcp_abort() and qla_nvme_ls_abort() ran INIT_WORK() on priv->abort_work immediately before schedule_work(). INIT_WORK() reinitializes the work_struct, resetting its list head and clearing the pending bit. If an abort is issued more than once for the same command (for example, concurrent transport teardown and a timeout-driven abort), the second INIT_WORK() reinitializes a work item that is already queued, which can corrupt the workqueue list and lead to crashes or a looping worker.
Initialize priv->abort_work once at command submission, next to the existing per-command spin_lock_init(&priv->cmd_lock), and leave only schedule_work() in the abort paths. schedule_work() already does nothing when the work item is still pending, so a repeated abort no longer disturbs an in-flight work item. The command is not returned to the transport until the final kref_put()/release callback runs after abort_work has completed, so the work item is idle before priv is reused and the single submission-time INIT_WORK() is safe.(CVE-2026-89860)
In the Linux kernel, the following vulnerability has been resolved:
NFSv4.2: fix LAYOUTSTATS send buffer exhaustion
encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that.
ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for.
The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held.
Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation.(CVE-2026-90103)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length
The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set.
Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf ("mt76x2: remove some harmless WARN_ONs in tx status and rx path") did for the neighboring rx and tx status paths.
Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel.(CVE-2026-90382)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xive: propagate IPI init errors to prevent use-after-free
When xive_init_ipis() fails (e.g. irq_domain_alloc_irqs() fails), the error path frees the global xive_ipis array. However, xive_smp_probe() previously ignored this failure and proceeded to call xive_setup_cpu_ipi(), which dereferences the already-freed xive_ipis pointer -- a use-after-free.
Now that xive_smp_probe() returns int (previous patch), propagate the error from xive_init_ipis() and xive_setup_cpu_ipi() through xive_smp_probe(). Check the return value in both pnv_smp_probe() and pSeries_smp_probe() so that IPI setup is aborted cleanly on failure, avoiding the use-after-free.(CVE-2026-93260)
In the Linux kernel, the following vulnerability has been resolved:
perf: Fix addr_filter_ranges lifetime
Lee Jia Jie reported that since event::addr_filter_ranges is used under RCU, it should be RCU freed.(CVE-2026-93817)
In the Linux kernel, the following vulnerability has been resolved:
HID: hidpp: fix potential UAF in hidpp_connect_event()
If input_register_device() fails, we call input_free_device(), but keep stale pointer to the old device in hidpp->input, which could potentially lead to UAF. Fix that by resetting it to NULL before returning from hidpp_connect_event().(CVE-2026-93826)
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: add boundary checks in two places
Add boundary checks in acpi_ps_get_next_namestring() and acpi_ps_peek_opcode() to prevent out-of-bounds access.(CVE-2026-97444)
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources()
Enhance buffer validation in acpi_ut_walk_aml_resources() to prevent buffer overflows.(CVE-2026-97445)
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Add validation for node in acpi_ns_build_normalized_path()
Add validation for node in acpi_ns_build_normalized_path() to prevent use-after-free vulnerabilities.(CVE-2026-97448)
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: validate handler object type in two places
ACPICA: validate handler object type in acpi_ev_has_default_handler() and acpi_ev_find_region_handler().(CVE-2026-97450)
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op)
Add overflow check for Index + Length to prevent integer overflow when calculating the truncation length. This prevents negative size parameter being passed to memcpy().(CVE-2026-97451)
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Prevent adding invalid references
Prevent adding references for local, argument, and debug objects in acpi_ut_copy_simple_object().(CVE-2026-97452)
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: add boundary checks in acpi_ps_get_next_field()
Add boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds access.(CVE-2026-97454)
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Fix use-after-free in acpi_ds_terminate_control_method()
Fix use-after-free issue in acpi_ds_terminate_control_method() by clearing references to method locals and arguments.(CVE-2026-97455)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Skip vport under deletion in report ID acquisition
qla24xx_report_id_acquisition() format-1 handling walks ha->vp_list under vport_slock, takes a vref_count on the matching vport and calls qla_update_host_map() to register its port id.
A vport teardown via qla24xx_vport_delete() sets VPORT_DELETE, then qla24xx_disable_vp() removes the vport from the host_map btree and zeroes vha->d_id (RESET_AL_PA). The vport is only unlinked from vp_list later, in qla24xx_deallocate_vp_id(), which clears vp_map[idx] (RESET_VP_IDX) but does not touch host_map. In the window in between, report ID acquisition can still find the vport on vp_list and call qla_update_host_map(); with d_id already zeroed it takes the btree_insert32() path and re-inserts the dying vport into host_map. Nothing cleans that entry afterwards, so once scsi_host_put() frees the vha a later host_map lookup dereferences freed memory.
Skip a vport that has VPORT_DELETE set before taking the reference, so it is neither re-registered nor scheduled for DPC re-registration. This mirrors the existing guard in qla2x00_alert_all_vps().(CVE-2026-97531)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown
The response queue MSI-X handler qla2xxx_msix_rsp_q() schedules qla_do_work() via queue_work(ha->wq, &qpair->q_work). qla_do_work() dereferences the qpair (vha, rsp) and takes qpair->qp_lock.
During teardown, qla2xxx_delete_qpair() deletes the response queue, which calls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and the qpair. free_irq() waits for running hardirq handlers but does not cancel work already placed on ha->wq. A still-pending q_work then runs qla_do_work() against the freed qpair and response queue, causing a use-after-free. This is especially likely during full adapter teardown, where destroy_workqueue(ha->wq) forces pending work to run after the queue pairs have been freed.
Flush the work item with cancel_work_sync() in qla25xx_free_rsp_que() after free_irq() has released the interrupt (so no new work can be queued) and before the response queue and qpair memory are freed (so the flushed handler still sees valid memory). Guard on rsp->qpair and ha->wq to match the INIT_WORK() condition and avoid operating on an uninitialized work_struct.(CVE-2026-97536)
In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-ctrls: validate HEVC tile counts
The stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from column_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[] and use them as tile-loop bounds, but std_validate_compound() does not bound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling enabled whose tile counts exceed the uAPI array capacity, mirroring the existing compound-control range checks.(CVE-2026-97576)
In the Linux kernel, the following vulnerability has been resolved:
net: mpls: clear inner_protocol when the last label is popped
skb_mpls_push() records the pre-encapsulation network header once, gated on !skb->inner_protocol. skb_mpls_pop() never clears that record, so it outlives the encapsulation it describes.
Open vSwitch can then re-push MPLS onto a packet whose inner_network_header still points at the older, deeper offset: push a label, pop every label, recirculate (ovs_flow_key_update() re-derives key->eth.type and resets network_header, but leaves inner_*), then push again. ovs_fragment() trusts the record:
skb->network_header = skb->inner_network_header;
so skb_network_offset() goes negative. The bound check is signed:
if (skb_network_offset(skb) > MAX_L2_LEN)
a negative offset passes it, and prepare_frag() widens the value:
unsigned int hlen = skb_network_offset(skb);
memcpy(&data->l2_data, skb->data, hlen);
which is a ~4GiB memcpy out of a 30-byte per-CPU buffer.
Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8):
BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 prepare_frag+0x3df/0x4e0 ovs_fragment+0x589/0x7e0 do_output+0x4ce/0x5e0 do_execute_actions+0x55d2/0x7b30 ovs_execute_actions+0xea/0x450
Same root-cause shape as commit 975b5b067f52 ("ipv6: sr: restore network header before routing and forwarding"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path.
Clear inner_protocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/act_mpls.c is the only other skb_mpls_pop() caller and gets the same fix; sch_frag.c saves and restores inner_protocol around fragmentation in the same way OVS does.(CVE-2026-97612)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Set the trace clock before registering the histogram trigger
hist_register_trigger() puts the trigger on the global named_triggers list in cmd_ops->init(), and only then sets the trace clock:
if (data->cmd_ops->init) {
ret = data->cmd_ops->init(data);
if (ret < 0)
goto out;
}
if (hist_data->enable_timestamps) {
ret = tracing_set_clock(file->tr, hist_data->attrs->clock);
if (ret) {
hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock));
goto out;
}
The clock string is not checked anywhere before that call, so a named trigger using common_timestamp with an unknown clock fails after it has already become findable. event_hist_trigger_parse() then frees it without taking it off the list, and the next lookup by name reads the freed object:
~# cd /sys/kernel/tracing/events/sched/sched_switch ~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=foo:keys=common_pid' > trigger
BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff88800915d760 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0x900 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 63: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160
Set the clock before the trigger is registered, so that nothing which can fail runs after it is published, the way commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers list") moved the registration below the rest of the setup.
tracing_set_filter_buffering() is reference counted, so the init failure path has to drop the reference that the clock block now takes first.(CVE-2026-97935)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix fib6 walker UAF on seq stop
ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed walker.
Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a never-started iterator with a zeroed private object is not treated as linked.
The same stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only widens the race.(CVE-2026-97940)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Don't predict JMP32 pointer vs zero comparisons
Consider the following program:
r1 = map_value; /* low 32 bits are zero at runtime */
r6 = 0xdead000000000000;
if w1 != 0 goto l1;
l0: r1 += r6;
r2 = *(u64 *)(r1 + 0);
exit;
l1: r6 = 0;
goto l0;
At the moment is_branch_taken() reports the jump as always taken, because it does not distinguish between BPF_JMP and BPF_JMP32 comparisons when processing 'if w1 != 0 ...'.(CVE-2026-98041)
In the Linux kernel, the following vulnerability has been resolved:
nvme: remove stale namespaces by NSID range during scan
nvme_scan_ns_list() drops the stale namespaces in each gap in the reported NSID list one NSID at a time. Every iteration calls nvme_find_get_ns() to look the namespace up and removes it if it is present. The loop runs once per NSID in the gap rather than once per namespace actually present.
NSIDs are 32-bit, so a target with a sparse NSID space can make a single gap spin the loop billions of times with nothing to remove.
watchdog: BUG: soft lockup - CPU#4 stuck for 26s! Workqueue: nvme-wq nvme_scan_work [nvme_core] RIP: 0010:__srcu_read_unlock+0xb/0x20 Call Trace: nvme_find_get_ns+0x7d/0xb0 [nvme_core] nvme_scan_ns_list+0xe8/0x280 [nvme_core] nvme_scan_work+0x18a/0x280 [nvme_core] process_one_work+0x197/0x380 worker_thread+0x2fe/0x410 kthread+0xe0/0x100
Rename nvme_remove_invalid_namespaces() to nvme_remove_nsid_range() and give it an open (start, end) NSID range. ctrl->namespaces is sorted by NSID, so the whole gap is dropped in a single walk that stops once end is reached. This bounds the work by the namespaces that are present instead of by the size of the gap.(CVE-2026-98056)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: restore network header before routing and forwarding
ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header.
When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative.
This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows.
Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back.(CVE-2026-98096)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan
l2cap_new_connection() sets default value of channel mode to match the parent channel. l2cap_le_connect_req() left this at the default, and created L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that mode. This causes FLAG_DEFER_SETUP channels to reply to L2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect.
It can also result to stack OOB write (of l2cap_alloc_cid determined values) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not limit maximum number of deferred channels or check for duplicate ident.
Fix by setting chan->mode correctly in l2cap_le_connect_req().
Also check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE instead of OOB write to make it less brittle.(CVE-2026-98108)
In the Linux kernel, the following vulnerability has been resolved:
KEYS: encrypted: fix integer overflow of datablob_len
encrypted_key_alloc() stores datablob_len in a u16. It is computed from multiple string and payload lengths. If the result exceeds U16_MAX, the assignment truncates the allocation size. KASAN reports a 32760-byte slab-out-of-bounds write when __ekey_init() copies the master key description into the undersized buffer.
The total payload length stored in key->datalen is also a u16. Use check_add_overflow() to reject values that do not fit either destination, and use kzalloc_flex() for the flexible-array allocation.(CVE-2026-98222)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: fix refcount bug in iwpm_get_nlmsg_request()
iwpm_get_nlmsg_request() initializes refcount after list_add_tail() making it accessible to global list where another CPU can kref_get() on nlmsg_request causing a refcount "addition on 0" bug. Fix this by initializing kref before list_add_tail() so refcount for nlmsg_request can be incremented/decremented normally. In addition, also initialize every field before list_add_tail().(CVE-2026-98252)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/ucma: Serialize join and leave on copy_to_user failure
rdma_join_multicast() queues RoCE work that later reads the ucma_multicast through event->param.ud.private_data, then list_add()s the CMA multicast at the head of id_priv->mc_list. rdma_leave_multicast() matches only by sockaddr and destroys the first hit.
ucma_process_join() used to drop ctx->mutex after a successful join and retake it only if copy_to_user() failed. Two concurrent JOIN_MCAST calls with the same address can therefore insert a second CMA entry before the first thread's leave. leave then cancels the newer work and the older worker still dereferences the ucma_multicast that the first thread frees.
Keep ctx->mutex held from rdma_join_multicast() through copy_to_user() and, on -EFAULT, through rdma_leave_multicast() so leave cannot miss this join. Do not leave if join itself failed: that path never published this address on mc_list, and a leave-by-addr would destroy an earlier successful join.(CVE-2026-98253)
In the Linux kernel, the following vulnerability has been resolved:
net: lock the socket in sock_gettstamp()
sk->sk_flags must only be changed while holding the socket lock, because sock_set_flag() and sock_reset_flag() use non atomic operations (__set_bit() and __clear_bit()).
sock_gettstamp() is one of the last places where a bit of sk->sk_flags is changed from a syscall without owning the socket lock, through sock_enable_timestamp(sk, SOCK_TIMESTAMP).
sk_set_memalloc() and sk_clear_memalloc() also change sk->sk_flags without the socket lock, but their callers (nbd, iscsi_tcp, nvme-tcp, sunrpc, wireguard) need a careful audit, this will be addressed in a separate patch.
Jungwoo Lee and Wongi Lee reported an UDP socket use-after-free caused by this bug: a SIOCGSTAMPNS_NEW ioctl racing with bind() can cancel the SOCK_RCU_FREE bit that udp_lib_get_port() just set, because both threads perform a read-modify-write on the same word.
CPU 0 (bind) CPU 1 (SIOCGSTAMPNS_NEW) -------------------------------- ---------------------------- read sk_flags = F read sk_flags = F compute F | BIT(SOCK_RCU_FREE) compute F | BIT(SOCK_TIMESTAMP) store F | BIT(SOCK_RCU_FREE) sk_add_node_rcu(sk, ...) store F | BIT(SOCK_TIMESTAMP)
After the lost update, SOCK_RCU_FREE is clear while the socket is visible to lockless UDP receive lookups. sk_destruct() then frees the socket immediately instead of waiting for a RCU grace period, while the receive path still holds a reference-less pointer to it:
BUG: KASAN: slab-use-after-free in ipv4_pktinfo_prepare+0x30/0x410 Read of size 8 at addr ffff888008806610 by task exploit/207 CPU: 0 UID: 1000 PID: 207 Comm: exploit Not tainted 6.12.95+ #1 ipv4_pktinfo_prepare+0x30/0x410 udp_queue_rcv_one_skb+0x51c/0x1180 udp_unicast_rcv_skb+0x109/0x350 ip_protocol_deliver_rcu+0x14b/0x310 ip_local_deliver_finish+0x29d/0x390 ip_local_deliver+0x24d/0x2a0
Only grab the socket lock when SOCK_TIMESTAMP has to be set, to keep the common case lockless.(CVE-2026-98276)
In the Linux kernel, the following vulnerability has been resolved:
IB/isert: wait for deferred control PDU completions before releasing the connection
isert_send_done() hands ISTATE_SEND_TASKMGTRSP, ISTATE_SEND_REJECT and ISTATE_SEND_TEXTRSP completions off to isert_comp_wq and returns. The work item then runs isert_completion_put() -> isert_put_cmd(), which reads isert_conn->conn and takes conn->cmd_lock.
Nothing orders that work item against teardown. isert_wait_conn() queues isert_release_work, which frees isert_conn, and iscsit_close_connection() frees the iscsit_conn right after it returns, so the queued work can run against freed memory.
Count the deferred control PDU completions per connection and let isert_wait_conn() wait for them before the release work is queued.
ISTATE_SEND_LOGOUTRSP is deliberately not counted: that branch runs iscsit_logout_post_handler(), which ends up waiting for conn->conn_wait_comp, and that completion is only sent by iscsit_close_connection() after it has called iscsit_wait_conn(). Waiting for it here would deadlock. Its wait stays the existing isert_wait4logout().
The splat below is from a kernel with tracing printk()s and an msleep(200) injected into isert_do_control_comp() to widen the window:
BUG: KASAN: slab-use-after-free in isert_put_cmd+0x53d/0x620 Read of size 8 at addr ffff8881054f1038 by task kworker/u17:1/182
CPU: 0 UID: 0 PID: 182 Comm: kworker/u17:1 Tainted: G B 7.2.0-rc5-TWIDE-gb8babf08acc7 #1 PREEMPT(lazy) Tainted: [B]=BAD_PAGE Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: isert_comp_wq isert_do_control_comp Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x3e/0x70 ? isert_put_cmd+0x53d/0x620 kasan_report+0xce/0x100 ? isert_put_cmd+0x53d/0x620 isert_put_cmd+0x53d/0x620 ? isert_completion_put+0x305/0x330 ? isert_do_control_comp+0x2ef/0x310 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 48: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_cache_noprof+0x158/0x370 isert_cma_handler+0x1e3/0x2ae0 cma_cm_event_handler+0x3e/0x240 cma_ib_req_handler+0x17d9/0x4490 cm_process_work+0x41/0x330 cm_work_handler+0x5727/0xc160 process_one_work+0x633/0x1030 worker_thread+0x45b/0xd10 kthread+0x2c6/0x3b0 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30
Freed by task 184: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x121/0x380 iscsit_close_connection+0x7cf/0x1e60 iscsit_take_action_for_connection_exit+0x1b6/0x360 iscsi_target_tx_thread+0x472/0x690 kthread+0x2c6/0x3b0 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30(CVE-2026-98357)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Reject unregistering netdevs in ib_get_eth_speed
ib_device_get_netdev() intentionally returns a referenced net_device even when it is unregistering, so matching and cleanup callers can still find the association. The reference keeps struct net_device allocated, but does not guarantee that the device remains operational.
ib_get_eth_speed() uses the returned device operationally by invoking its ethtool callback. Although that call is made under RTNL, the function does not verify the registration state first. An asynchronous RDMA port query can therefore call into a netdev after NETDEV_UNREGISTER and ndo_uninit have completed.
Check for NETREG_REGISTERED while holding RTNL and return -ENODEV for a device which is being unregistered. Keeping RTNL across the check and the ethtool operation prevents unregister from starting between them.
Keep the speed fallback and warning under RTNL as well, so the warning can safely read netdev->name. Drop the netdev reference before releasing RTNL once all accesses to the device are complete.(CVE-2026-98359)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB access
mr_check_range() validates that [iova, iova+length) falls within the registered MR range using wraparound-prone arithmetic:
if (iova < mr->ibmr.iova ||
iova + length > mr->ibmr.iova + mr->ibmr.length)
A remote peer can craft an RDMA-Write/Read RETH so that iova + length wraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing the check. rxe_mr_iova_to_index() then computes a huge index (int idx, only guarded by WARN_ON) and rxe_mr_copy_xarray() dereferences mr->page_info[huge], causing an out-of-bounds read/write and a kernel oops that is triggerable by an unauthenticated remote peer.
Rewrite the check in overflow-safe form; the first two clauses guarantee that the subsequent subtractions do not underflow:
if (iova < mr->ibmr.iova ||
length > mr->ibmr.length ||
iova - mr->ibmr.iova > mr->ibmr.length - length)
With the fix, mr_check_range() returns -EINVAL for the crafted iova and the responder reports REMOTE_ACCESS_ERROR instead of triggering the OOB.(CVE-2026-98365)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: validate checksum_start before completing checksum
If a packet with bad checksum metadata gets into the ipv4 stack, skb_checksum_help can corrupt the network header and cause a bunch of mischief.
This was discovered and reported by Paulos, and has been reporoduced by others independently since.
We really shouldn't allow such packets in, but as a defence in depth measure, let's also check before we complete the checksum.
A more complete validation at input is forthcoming, but needs more work.(CVE-2026-99999)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"perf-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-339.0.0.240.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"perf-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-339.0.0.240.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: clear extent cache after moving/defragmenting extents\n\nThe extent map cache can become stale when extents are moved or\ndefragmented, causing subsequent operations to see outdated extent flags. \nThis triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().\n\nThe problem occurs when:\n1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED\n2. ioctl(FITRIM) triggers ocfs2_move_extents()\n3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)\n4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent()\n which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)\n5. The extent map cache is not invalidated after the move\n6. Later write() operations read stale cached flags (0x2) but disk has\n updated flags (0x0), causing a mismatch\n7. BUG_ON(!(rec-\u0026gt;e_flags \u0026amp; OCFS2_EXT_REFCOUNTED)) triggers\n\nFix by clearing the extent map cache after each extent move/defrag\noperation in __ocfs2_move_extents_range(). This ensures subsequent\noperations read fresh extent data from disk.(CVE-2025-40233)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: properly keep track of conduit reference\n\nProblem description\n-------------------\n\nDSA has a mumbo-jumbo of reference handling of the conduit net device\nand its kobject which, sadly, is just wrong and doesn\u0026apos;t make sense.\n\nThere are two distinct problems.\n\n1. The OF path, which uses of_find_net_device_by_node(), never releases\n the elevated refcount on the conduit\u0026apos;s kobject. Nominally, the OF and\n non-OF paths should result in objects having identical reference\n counts taken, and it is already suspicious that\n dsa_dev_to_net_device() has a put_device() call which is missing in\n dsa_port_parse_of(), but we can actually even verify that an issue\n exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command\n \u0026quot;before\u0026quot; and \u0026quot;after\u0026quot; applying this patch:\n\n(unbind the conduit driver for net device eno2)\necho 0000:00:00.2 \u0026gt; /sys/bus/pci/drivers/fsl_enetc/unbind\n\nwe see these lines in the output diff which appear only with the patch\napplied:\n\nkobject: \u0026apos;eno2\u0026apos; (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)\nkobject: \u0026apos;109\u0026apos; (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)\n\n2. After we find the conduit interface one way (OF) or another (non-OF),\n it can get unregistered at any time, and DSA remains with a long-lived,\n but in this case stale, cpu_dp-\u0026gt;conduit pointer. Holding the net\n device\u0026apos;s underlying kobject isn\u0026apos;t actually of much help, it just\n prevents it from being freed (but we never need that kobject\n directly). What helps us to prevent the net device from being\n unregistered is the parallel netdev reference mechanism (dev_hold()\n and dev_put()).\n\nActually we actually use that netdev tracker mechanism implicitly on\nuser ports since commit 2f1e8ea726e9 (\u0026quot;net: dsa: link interfaces with\nthe DSA master to get rid of lockdep warnings\u0026quot;), via netdev_upper_dev_link().\nBut time still passes at DSA switch probe time between the initial\nof_find_net_device_by_node() code and the user port creation time, time\nduring which the conduit could unregister itself and DSA wouldn\u0026apos;t know\nabout it.\n\nSo we have to run of_find_net_device_by_node() under rtnl_lock() to\nprevent that from happening, and release the lock only with the netdev\ntracker having acquired the reference.\n\nDo we need to keep the reference until dsa_unregister_switch() /\ndsa_switch_shutdown()?\n1: Maybe yes. A switch device will still be registered even if all user\n ports failed to probe, see commit 86f8b1c01a0a (\u0026quot;net: dsa: Do not\n make user port errors fatal\u0026quot;), and the cpu_dp-\u0026gt;conduit pointers\n remain valid. I haven\u0026apos;t audited all call paths to see whether they\n will actually use the conduit in lack of any user port, but if they\n do, it seems safer to not rely on user ports for that reference.\n2. Definitely yes. We support changing the conduit which a user port is\n associated to, and we can get into a situation where we\u0026apos;ve moved all\n user ports away from a conduit, thus no longer hold any reference to\n it via the net device tracker. But we shouldn\u0026apos;t let it go nonetheless\n - see the next change in relation to dsa_tree_find_first_conduit()\n and LAG conduits which disappear.\n We have to be prepared to return to the physical conduit, so the CPU\n port must explicitly keep another reference to it. This is also to\n say: the user ports and their CPU ports may not always keep a\n reference to the same conduit net device, and both are needed.\n\nAs for the conduit\u0026apos;s kobject for the /sys/class/net/ entry, we don\u0026apos;t\ncare about it, we can release it as soon as we hold the net device\nobject itself.\n\nHistory and blame attribution\n-----------------------------\n\nThe code has been refactored so many times, it is very difficult to\nfollow and properly attribute a blame, but I\u0026apos;ll try to make a short\nhistory which I hope to be correct.\n\nWe have two distinct probing paths:\n- one for OF, introduced in 2016 i\n---truncated---(CVE-2025-71152)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix out-of-bounds write in ocfs2_write_end_inline\n\nKASAN reports a use-after-free write of 4086 bytes in\nocfs2_write_end_inline, called from ocfs2_write_end_nolock during a\ncopy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on\na loop device. The actual bug is an out-of-bounds write past the inode\nblock buffer, not a true use-after-free. The write overflows into an\nadjacent freed page, which KASAN reports as UAF.\n\nThe root cause is that ocfs2_try_to_write_inline_data trusts the on-disk\nid_count field to determine whether a write fits in inline data. On a\ncorrupted filesystem, id_count can exceed the physical maximum inline data\ncapacity, causing writes to overflow the inode block buffer.\n\nCall trace (crash path):\n\n vfs_copy_file_range (fs/read_write.c:1634)\n do_splice_direct\n splice_direct_to_actor\n iter_file_splice_write\n ocfs2_file_write_iter\n generic_perform_write\n ocfs2_write_end\n ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949)\n ocfs2_write_end_inline (fs/ocfs2/aops.c:1915)\n memcpy_from_folio \u0026lt;-- KASAN: write OOB\n\nSo add id_count upper bound check in ocfs2_validate_inode_block() to\nalongside the existing i_size check to fix it.(CVE-2026-43075)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: Limit XDomain response copy to actual frame size\n\ntb_xdomain_copy() copies req-\u0026gt;response_size bytes from the received\npacket buffer regardless of the actual frame size. When a short\nresponse arrives, this reads past the valid frame data in the DMA\npool buffer into stale contents from previous transactions.\n\nUse the minimum of frame size and expected response size for the\ncopy length.(CVE-2026-53146)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: update file PMD counter before folio_put()\n\n__split_huge_pmd_locked() updates the file/shmem RSS counter after\ndropping the PMD mapping\u0026apos;s folio reference. If folio_put() drops the last\nreference, mm_counter_file() can later read freed folio state via\nfolio_test_swapbacked().\n\nMove the counter update before folio_put().(CVE-2026-53189)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: bnep: reject short frames before parsing\n\nA BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the\npacket type byte immediately and, for control packets, reads the control\nopcode and setup UUID-size byte before proving that those bytes are\npresent. bnep_rx_control() also dereferences the control opcode without\nrejecting an empty control payload.\n\nUse skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL\nreturn gates each dereference. Split the control handler so the frame\npath can pass an opcode that has already been pulled, and keep the\nbyte-buffer wrapper for extension control payloads.\n\nFor BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the\nsetup payload. struct bnep_setup_conn_req carries destination and source\nservice UUIDs after that byte, each uuid_size bytes, so the parser now\ndocuments that tuple explicitly instead of leaving the pull length as an\nopaque multiplication.\n\nValidation reproduced this kernel report:\nKASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790\nThe buggy address belongs to the object at ffff88800c0f7908 which belongs\nto the cache kmalloc-8 of size 8\nThe buggy address is located 0 bytes to the right of allocated 1-byte\nregion [ffff88800c0f7908, ffff88800c0f7909)\nRead of size 1\nCall trace:\n dump_stack_lvl+0xb3/0x140 (?:?)\n print_address_description+0x57/0x3a0 (?:?)\n bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306)\n print_report+0xb9/0x2b0 (?:?)\n __virt_addr_valid+0x1ba/0x3a0 (?:?)\n srso_alias_return_thunk+0x5/0xfbef5 (?:?)\n kasan_addr_to_slab+0x21/0x60 (?:?)\n kasan_report+0xe0/0x110 (?:?)\n process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200)\n worker_thread+0x65c/0xe40 (?:?)\n __kthread_parkme+0x184/0x230 (?:?)\n kthread+0x35e/0x470 (?:?)\n _raw_spin_unlock_irq+0x28/0x50 (?:?)\n ret_from_fork+0x586/0x870 (?:?)\n __switch_to+0x74f/0xdc0 (?:?)\n ret_from_fork_asm+0x1a/0x30 (?:?)(CVE-2026-53253)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: validate skb length in MCC handlers\n\nThe RFCOMM MCC handlers cast skb-\u0026gt;data to protocol-specific structs\nwithout validating skb-\u0026gt;len first. A malicious remote device can send\ntruncated MCC frames and trigger out-of-bounds reads in these handlers.\n\nFix this by using skb_pull_data() to validate and access the required\ndata before dereferencing it.\n\nrfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows\n1-byte RPN requests. Handle this by validating only the DLCI byte first,\nand validating the full struct only when len \u0026gt; 1.(CVE-2026-53254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack: destroy stale expectfn expectations on unregister\n\nNAT helpers such as nf_nat_h323 store a raw pointer to module text in\nexp-\u0026gt;expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister()\nonly unlinks the callback descriptor and never walks the expectation table,\nso an expectation pending at module removal survives with a dangling\nexp-\u0026gt;expectfn into freed module text.\n\nWhen the expected connection arrives, init_conntrack() invokes\nexp-\u0026gt;expectfn(), now a stale pointer into the unloaded module. Reproduced\non a KASAN build by loading the H.323 helpers, creating a Q.931\nexpectation, unloading nf_nat_h323, then connecting to the expected port:\n\n Oops: int3: 0000 [#1] SMP KASAN NOPTI\n RIP: 0010:0xffffffffa06102d1\n init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862)\n nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049)\n ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223)\n nf_hook_slow (net/netfilter/core.c:619)\n __ip_local_out (net/ipv4/ip_output.c:120)\n __tcp_transmit_skb (net/ipv4/tcp_output.c:1715)\n tcp_connect (net/ipv4/tcp_output.c:4374)\n tcp_v4_connect (net/ipv4/tcp_ipv4.c:345)\n __sys_connect (net/socket.c:2167)\n Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323]\n\nReaching the dangling state requires CAP_SYS_MODULE in the initial user\nnamespace to remove a NAT helper that still has live expectations, so this\nis a robustness fix; leaving an expectation pointing at freed text is wrong\nregardless.\n\nAdd nf_ct_helper_expectfn_destroy(), which walks the expectation table and\ndrops every expectation whose -\u0026gt;expectfn matches the descriptor being torn\ndown. Call it from each NAT helper\u0026apos;s exit path after the existing RCU grace\nperiod, so no expectation outlives the code it points at and no extra\nsynchronize_rcu() is introduced. With the fix, the same reproducer runs to\ncompletion without the Oops.(CVE-2026-53349)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs3: reject direct userspace writes to reserved $LX* xattrs\n\nNTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL\npermission metadata and reloads them into i_uid, i_gid and i_mode\nfrom ntfs_get_wsl_perm().\n\nBecause the empty-prefix xattr handler also lets file owners call\nsetxattr() on these names directly, an unprivileged writer on a\nwritable ntfs3 mount can plant root ownership and S_ISUID on their own\nfile and gain euid 0 after inode reload.\n\nReject direct userspace writes to the reserved $LX* names. Internal\nntfs3 metadata updates are unchanged because ntfs_save_wsl_perm()\nwrites them via ntfs_set_ea() directly.\n\n[(CVE-2026-63833)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: synaptics-rmi4 - bound the F3A keymap to the GPIO count\n\nrmi_f3a_initialize() takes the GPIO count from the device query register\n(f3a-\u0026gt;gpio_count = buf \u0026amp; RMI_F3A_GPIO_COUNT, range 0..127).\nrmi_f3a_map_gpios() then allocates gpio_key_map with\nmin(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but\nrmi_f3a_attention() iterates the full gpio_count and dereferences\ngpio_key_map[i], and input-\u0026gt;keycodemax is set to the full gpio_count\nwhile input-\u0026gt;keycode points at the 6-entry allocation.\n\nA device that reports gpio_count \u0026gt; 6 therefore causes an out-of-bounds\nread of gpio_key_map[] on every attention interrupt, and out-of-bounds\naccesses through the input core\u0026apos;s default keymap ioctls: EVIOCGKEYCODE\nreads past the buffer (leaking adjacent slab memory to user space) and\nEVIOCSKEYCODE writes a caller-controlled value past it, for any process\nable to open the evdev node, since input_default_getkeycode() and\ninput_default_setkeycode() only bound the index against keycodemax.\n\nSize the keymap for the full gpio_count. The mapping loop is unchanged:\nit still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END)\nentries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills)\nand are skipped when reporting.(CVE-2026-64277)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: appleir: fix UAF on pending key_up_timer in remove()\n\nappleir_remove() runs hid_hw_stop() before timer_delete_sync().\nhid_hw_stop() synchronously unregisters the HID input device via\nhid_disconnect() -\u0026gt; hidinput_disconnect() -\u0026gt; input_unregister_device(),\nwhich drops the last reference and frees the underlying input_dev when\nno userspace handle holds it open.\n\nkey_up_tick() reads appleir-\u0026gt;input_dev and calls input_report_key() /\ninput_sync() on it. The timer is armed from appleir_raw_event() with\na HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a\nkey was pressed shortly before the device is disconnected, the timer\ncan fire after hid_hw_stop() has freed input_dev but before the\nteardown drains it.\n\nA simple reorder is not sufficient. Putting the timer drain first\nstill leaves a window where a USB URB completion (raw_event) running\nduring hid_hw_stop() can call mod_timer() and re-arm the timer, which\nthen fires after hidinput_disconnect() has freed input_dev. The same\nURB-completion window also lets raw_event() reach key_up(), key_down()\nand battery_flat() directly, all of which dereference\nappleir-\u0026gt;input_dev.\n\nIntroduce a \u0026apos;removing\u0026apos; flag on struct appleir, gated by the existing\nspinlock. appleir_remove() sets the flag under the lock and then\nshuts down the timer with timer_shutdown_sync(), which both drains any\nin-flight callback and permanently disables further mod_timer() calls.\nappleir_raw_event() and key_up_tick() bail out early if the flag is\nset, so no path can arm or run the timer, or dereference\nappleir-\u0026gt;input_dev, after remove() has started tearing down.\n\nThe keyrepeat and flatbattery branches of appleir_raw_event()\npreviously called into the input layer without holding the spinlock;\ntake it now so the flag check is well-defined. This incidentally\ncloses a pre-existing read-side race on appleir-\u0026gt;current_key in the\nkeyrepeat branch.\n\nThis bug is structurally a sibling of commit 4db2af929279 (\u0026quot;HID:\nappletb-kbd: fix UAF in inactivity-timer cleanup path\u0026quot;) and has been\npresent since the driver was introduced.(CVE-2026-64363)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: bound NTFS_DE view.data_off in UpdateRecordData{Root,Allocation}\n\nIn do_action()\u0026apos;s UpdateRecordDataRoot (fslog.c:3489) and\nUpdateRecordDataAllocation (fslog.c:3697) cases, the memmove\ndestination is `Add2Ptr(e, le16_to_cpu(e-\u0026gt;view.data_off))`,\nwhere e-\u0026gt;view.data_off comes from an on-disk NTFS_DE inside\nan INDEX_ROOT or INDEX_BUFFER. Neither case validates\nview.data_off + dlen against e-\u0026gt;size; the existing\ncheck_if_index_root / check_if_alloc_index helpers walk the\nentry chain and validate the entry\u0026apos;s offset, but not its\ninternal view fields.\n\nThe neighbouring read sites (e.g., fs/ntfs3/index.c when\niterating view entries) check view.data_off + view.data_size\n\u0026lt;= e-\u0026gt;size. Apply the same bound at the two memmove sites.\n\nReproduced under UML+KASAN on mainline 8d90b09e6741 via\npr_warn-only probe instrumentation: with view.data_off forced\nto 0xFFFC, the memmove writes 32 bytes past the end of the\nNTFS_DE.\n\nThis is similar in shape to Pavitra Jha\u0026apos;s 2026-05-02 patch\n\u0026quot;fs/ntfs3: prevent oob in case UpdateRecordDataRoot\u0026quot;\n(\u0026lt;(CVE-2026-64532)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket\n\nsmc_cdc_rx_handler() looks up the connection by token under the link\ngroup\u0026apos;s conns_lock, drops the lock, and then dereferences conn and the\nsmc_sock derived from it, ending in sock_hold(\u0026amp;smc-\u0026gt;sk) inside\nsmc_cdc_msg_recv(). No reference is held across the lock release.\n\nThe only reference pinning the socket while the connection is\ndiscoverable in the link group is taken in smc_lgr_register_conn()\n(sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both\nunder conns_lock. Once the handler drops conns_lock, a concurrent\nclose() -\u0026gt; smc_release() -\u0026gt; smc_conn_free() -\u0026gt; smc_lgr_unregister_conn()\ncan drop that reference and free the smc_sock, so the handler\u0026apos;s later\nsock_hold() runs on freed memory:\n\n WARNING: lib/refcount.c:25 at refcount_warn_saturate\n Workqueue: rxe_wq do_work\n refcount_warn_saturate (lib/refcount.c:25)\n smc_cdc_msg_recv (net/smc/smc_cdc.c:430)\n smc_cdc_rx_handler (net/smc/smc_cdc.c:502)\n smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445)\n tasklet_action_common (kernel/softirq.c:938)\n handle_softirqs (kernel/softirq.c:622)\n Kernel panic - not syncing: panic_on_warn set\n\nOnly SMC-R is affected. The SMC-D receive tasklet is stopped by\ntasklet_kill(\u0026amp;conn-\u0026gt;rx_tsklet) in smc_conn_free() before the connection\nis unregistered, so it cannot run concurrently with the free.\n\nTake the socket reference while still holding conns_lock, so the\nregistration reference can no longer be the last one, and drop it once\nthe handler is done.(CVE-2026-64541)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btrtl: validate firmware patch bounds\n\nrtlbt_parse_firmware() copies patch_length - 4 bytes before appending the\nfirmware version. A malformed firmware patch shorter than the version field\ncan make this subtraction underflow and turn the copy into an oversized\nread and write during Bluetooth setup.\n\nThe existing patch_offset + patch_length check can also wrap on 32-bit\narchitectures. Validate the patch length and range without arithmetic\noverflow before allocating or copying the patch.(CVE-2026-68479)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set\n\nWhen a USB audio endpoint requests full packet transfers via the fill_max\ndescriptor flag, data_ep_set_params() promotes ep-\u0026gt;curpacksize to\nep-\u0026gt;maxpacksize. However, maxsize is left at the original sample-rate\nderived value.\n\nSince u-\u0026gt;buffer_size is allocated as maxsize * packets, the resulting\nDMA buffer is far too small for the requested transfer length. When the\nUSB host controller streams up to curpacksize bytes per packet, it writes\npast the end of the buffer via DMA, corrupting kernel heap memory.\n\nUpdate maxsize to curpacksize when fill_max is set so that the allocated\nDMA buffer size matches the actual transfer request size.\n\n[ changed to reassign maxsize only when ep-\u0026gt;fill_max is set -- tiwai ](CVE-2026-74498)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: HIDP: validate numbered report payloads\n\nWhen hidp_get_raw_report() waits for a numbered report,\nhidp_process_data() compares the expected report number with skb-\u0026gt;data[0].\nA connected HIDP peer can reply with only a DATA transaction header,\nleaving the skb empty after the header is removed.\n\nKMSAN reports an uninitialized-value use in hidp_session_run(), with the\nvalue originating in __alloc_skb() through vhci_write(). The transaction\nheader checks remove the empty-frame reports, but this report remains until\nthe payload check is added.\n\nThe comparison can also consume a peer-controlled byte beyond the declared\nL2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made\nthe current code accept that byte as report ID 1 and complete\nHIDIOCGFEATURE with a zero-byte result. With this change the malformed\nresponse is rejected with -EIO, while a subsequent valid response still\nsucceeds.\n\nRequire a payload byte before comparing a numbered report ID. Unnumbered\nreports continue to accept an empty payload.(CVE-2026-74507)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: HIDP: reject frames without a transaction header\n\nhidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb-\u0026gt;data[0]\nbefore checking that the L2CAP SDU contains a transaction header. A\nconnected HIDP peer can send an empty basic-mode SDU and make both paths\nuse an uninitialized byte from skb tailroom.\n\nKMSAN reports the use in hidp_session_run(), with the uninitialized value\noriginating in __alloc_skb() through vhci_write(). The control path\nproduces two reports and the interrupt path produces one.\n\nThe byte can also be controlled by a malformed lower-layer packet. If an\nHCI ACL packet contains an L2CAP PDU with a declared zero-length payload\nfollowed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb-\u0026gt;len to\nthe declared PDU length before dispatch. The current HIDP path nevertheless\nconsumes the extra byte as HIDP_TRANS_HID_CONTROL |\nHIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this\nchange, the same packet is discarded and a subsequent feature report\nrequest succeeds.\n\nPull the transaction header with skb_pull_data() and discard frames that\ndo not contain it.(CVE-2026-74508)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: clear suppressed fib6 rule result\n\nfib6_rule_suppress() drops a suppressed route with ip6_rt_put_flags(),\nbut leaves res-\u0026gt;rt6 pointing at the released rt6_info.\n\nIf no later rule supplies a replacement, fib6_rule_lookup() still sees\nres.rt6 and returns that stale dst to its caller. A suppressing rule can\ntherefore leak a released route back to rt6_lookup(), and the next put\nhits rcuref_put_slowpath() from dst_release().\n\nClear res-\u0026gt;rt6 when suppressing the route so suppressed lookups fall\nthrough to the null dst instead of reusing the released one.(CVE-2026-74581)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_route: fix fastmap use-after-free on filter\n\nThe route4 classifier maintains a 16-slot fastmap cache that stores raw\nstruct route4_filter pointers indexed by (id, iif). The reader\n(route4_classify) populates this cache via route4_set_fastmap() for every\nclassified packet that hits a filter. The writer (route4_delete,\nroute4_change) clears the cache via route4_reset_fastmap() before\nRCU-deferred kfree of the filter.\n\nThis creates a UAF race:\n 1. Reader walks the RCU-protected bucket chain, finds filter f\n 2. Writer unlinks f, calls route4_reset_fastmap(), then tcf_queue_work()\n 3. Reader calls route4_set_fastmap() and writes f into the cache\n *after* the writer\u0026apos;s reset, caching a pointer about to be freed\n 4. After the RCU grace period, kfree(f) executes\n 5. Next classified packet on the same (id, iif) tuple hits the stale\n fastmap entry and reads f-\u0026gt;res from freed memory\n\nReproduced with an mdelay(100) accelerator in route4_set_fastmap() and a\nconcurrent add/delete stress test (provided by both zdi and Santosh).\nBoth triggered KASAN slab-use-after-free reports in the route4 fastmap\npaths.\n\nFix:\nIntroduce a per-filter boolean dying flag to suppress stale fastmap\nrepublishing by in-flight readers.(CVE-2026-74583)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent in6_dev_get() from resurrecting inet6_dev\n\nin6_dev_get() reads dev-\u0026gt;ip6_ptr under RCU and then unconditionally\nincrements its refcount. Device teardown can clear the pointer and drop\nthe last reference between these operations. The increment then\nresurrects an object whose RCU free has already been queued, so callers\ncan use it after it is freed.\n\nUse refcount_inc_not_zero() and return NULL when the object has already\nreached zero. RCU keeps the memory accessible through the attempted\nreference acquisition, and a successful increment pins the object for\nthe caller.\n\nAn independent run on the exact unpatched 6f5156d7a31a (v7.2-rc3)\nkernel reproduced the invalid reference acquisition as UID 1000:\n\n refcount_t: addition on 0; use-after-free.\n ip6_mc_source+0xef4/0x17e0\n\nIt was followed by the corresponding reference underflow in\nip6_mc_source(). The supplied trace from the same unpatched revision\nadditionally shows the access after the RCU read-side section ends:\n\n BUG: KASAN: slab-use-after-free in mutex_lock+0x76/0xe0\n Write of size 8 at addr ffff888015b50240 by task poc/1219\n\nBug found and triaged by OpenAI Security Research and\nvalidated by Trail of Bits.(CVE-2026-74630)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_u32: skip hash tables in u32_bind_class()\n\nu32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode\nthrough the walker callback. u32_bind_class() unconditionally casts the\npassed fh to tc_u_knode and accesses \u0026amp;n-\u0026gt;res, so when fh is actually a\ntc_u_hnode, which has no tcf_result member, this results in a\nslab-out-of-bounds read of res-\u0026gt;classid in tc_cls_bind_class().\n\nThe issue can be reproduced with the following commands:\n\n tc qdisc add dev lo root handle 1: hfsc\n tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit\n tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1\n tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit\n\nFix this by skipping hash tables via the TC_U32_KEY(handle) check.(CVE-2026-74739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ninet: frags: strip GSO state from fragments before reassembly\n\nA virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark\nan IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off.\ninet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first\nfragment\u0026apos;s skb as the head of the reassembled datagram, including its\nshinfo-\u0026gt;gso_size/gso_type/gso_segs, and chain the remaining fragments\non frag_list with whatever linear/paged layout they arrived with.\n\nAfter ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the\nreassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and\nthe next software segmentation point - udp_rcv_segment() on local\ndelivery, validate_xmit_skb(), or the ip_finish_output_gso() slow\npath - hands it to skb_segment(). skb_segment()\u0026apos;s frag_list walk\nassumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to\na tap by an unprivileged user in its own userns are enough:\n\n kernel BUG at net/core/skbuff.c:4899!\n Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\n CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2\n RIP: 0010:skb_segment+0x20ca/0x48b0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __udp_gso_segment+0x29a/0x27d0\n udp4_ufo_fragment+0x458/0x6c0\n inet_gso_segment+0x429/0x1340\n skb_mac_gso_segment+0x233/0x4f0\n __skb_gso_segment+0x308/0x660\n udp_queue_rcv_skb+0x440/0xad0\n udp_unicast_rcv_skb+0xc7/0x2c0\n udp_rcv+0x16ce/0x2260\n ip_protocol_deliver_rcu+0x197/0x2d0\n ip_local_deliver+0x430/0x690\n ip_rcv+0x16f/0x1f0\n __netif_receive_skb_one_core+0x15e/0x1c0\n __netif_receive_skb+0x1e/0x110\n netif_receive_skb+0xf6/0x5c0\n tun_rx_batched.isra.0+0x3ab/0x790\n tun_get_user+0x17c3/0x3550\n tun_chr_write_iter+0xba/0x1b0\n vfs_write+0x646/0x1130\n \u0026lt;/TASK\u0026gt;\n Kernel panic - not syncing: Fatal exception in interrupt\n\nThis runs with BH disabled, so it is a panic rather than an oops. The\nsame is reachable with CAP_NET_RAW in a netns where a defrag point\nprecedes a GSO point, and from a guest whose VMM forwards\nvirtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by\ncommit 3dcbdb134f32 (\u0026quot;net: gso: Fix skb_segment splat when splitting\ngso_size mangled skb having linear-headed frag_list\u0026quot;) and by\ncommit 9e4b7a99a03a (\u0026quot;net: gso: fix panic on frag_list with mixed head\nalloc types\u0026quot;) do not cover it: page-backed heads skip them, and kmalloc\nheads skip them when gso_size == skb_headlen(head), which the sender\ncontrols.\n\nAn skb entering a frag queue is an IP fragment by definition and\ncannot legitimately carry GSO state: GRO does not merge fragments and\nthe stack segments before it fragments, so only untrusted sources are\naffected. This has been reachable since\ncommit f43798c27684 (\u0026quot;tun: Allow GSO using virtio_net_hdr\u0026quot;), the first\npath that let userspace attach GSO metadata to an IP fragment. Reset\nthe GSO fields of every fragment as it is queued, in\ninet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and\n6lowpan reassembly share; then neither the head nor the frag_list\nmembers of the reassembled skb carry them (the members matter too:\nthe ip_do_fragment()/ip6_fragment() fast paths send them out as they\nare). The head may remain CHECKSUM_PARTIAL; that is already accepted\non receive and resolved by skb_checksum_help() in\nip_do_fragment()/ip6_fragment() on forward.\n\nTested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer\nabove, two further IPv4 frag_list geometries that reach\nBUG_ON(i \u0026gt;= nfrags) and BUG_ON(!list_skb-\u0026gt;head_frag), and an IPv6\nfragment-header variant (udp6_ufo_fragment()) each panic the unpatched\nkernel; with this patch all four datagrams are delivered intact and\nnothing is logged.(CVE-2026-80590)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: re-fetch eth header after route_shortcircuit()\n\nBefore route_shortcircuit(), the eth header pointer is cached from eth_hdr(skb).\n\nInside route_shortcircuit(), pskb_may_pull() can be called, which may\nreallocate skb-\u0026gt;head.\n\nIn this case, returning to vxlan_xmit() leaves the cached eth pointer pointing to\nfreed memory, leading to a use-after-free when dereferencing eth-\u0026gt;h_dest.\n\nFix this by updating eth = eth_hdr(skb) after calling route_shortcircuit().(CVE-2026-80681)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: do not propagate one-packet flag to synced conns\n\nSynced connections can be created before their destination exists. When\nthe destination is later added, ip_vs_bind_dest() copies connection flags\nfrom the destination into cp-\u0026gt;flags.\n\nIP_VS_CONN_F_ONE_PACKET connections are not synced. If a synced\nconnection inherits IP_VS_CONN_F_ONE_PACKET while it is already hashed,\nexpiry can treat it as a one-packet connection and skip unlinking the\nexisting conn_tab node, leaving stale hash nodes pointing at a freed\nstruct ip_vs_conn.\n\nDrop IP_VS_CONN_F_ONE_PACKET from destination flags when binding synced\nconnections.(CVE-2026-80714)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nslip: fix use-after-free in sl_sync()\n\nslip_devs[] stores bare net_device pointers and takes no reference on\nthem. sl_sync() and sl_alloc() walk that table from slip_open() under\nrtnl_lock(), while an entry is dropped by sl_free_netdev(), which\nsl_setup() installs as dev-\u0026gt;priv_destructor.\n\npriv_destructor is called from netdev_run_todo(), which deliberately\nruns with the RTNL semaphore released so that it can sleep while waiting\nfor the device refcount to drop:\n\n\t/* Snapshot list, allow later requests */\n\tlist_replace_init(\u0026amp;net_todo_list, \u0026amp;list);\n\n\t__rtnl_unlock();\n\t...\n\t\tif (dev-\u0026gt;priv_destructor)\n\t\t\tdev-\u0026gt;priv_destructor(dev);\t/* slip_devs[i] = NULL */\n\t\tif (dev-\u0026gt;needs_free_netdev)\n\t\t\tfree_netdev(dev);\n\t\t...\n\t\t/* Free network device */\n\t\tkobject_put(\u0026amp;dev-\u0026gt;dev.kobj);\n\nSo rtnl_lock() does not serialise slip_open() against the teardown at\nall. sl_sync() can load slip_devs[i] while the entry is still published\nand dereference it after netdev_run_todo() has run the destructor and\nreleased the device:\n\n CPU0 (slip_open) CPU1 (slip_close)\n unregister_netdev()\n rtnl_unlock()\n netdev_run_todo()\n __rtnl_unlock()\n rtnl_lock()\n sl_sync()\n dev = slip_devs[i]\n priv_destructor(dev)\n slip_devs[i] = NULL\n kobject_put(\u0026amp;dev-\u0026gt;dev.kobj)\n /* dev is freed */\n sl = netdev_priv(dev)\n if (sl-\u0026gt;tty || sl-\u0026gt;leased) /* use-after-free */\n\n BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline]\n BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806\n Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506\n\n CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\n Call Trace:\n sl_sync drivers/net/slip/slip.c:730 [inline]\n slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806\n tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433\n tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564\n tiocsetd drivers/tty/tty_io.c:2428 [inline]\n tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712\n\n Allocated by task 6502:\n alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719\n sl_alloc drivers/net/slip/slip.c:756 [inline]\n slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817\n tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433\n tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564\n\n Freed by task 6497:\n device_release+0xa2/0x240 drivers/base/core.c:2507\n kobject_put+0x179/0x280 lib/kobject.c:729\n netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509\n slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906\n tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456\n tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614\n tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782\n tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860\n\nCommit e58c19124189 (\u0026quot;slip: Fix use-after-free Read in slip_open\u0026quot;) fixed\na different source of stale entries - a device left in slip_devs[] after\nslip_open() freed it on the registration error path - and does not\naddress this race, which is why the report survives it.\n\nDrop the entry from ndo_uninit instead. unregister_netdevice() calls\nndo_uninit under RTNL, before the device is queued to netdev_run_todo(),\nso an entry that sl_sync() can still see while holding RTNL belongs to a\ndevice that cannot be freed until RTNL is dropped. sl_free_netdev()\nstays only for the slip_open() error path, where register_netdevice()\nmay have failed before ndo_init and ndo_uninit is then not called\neither. Both running for the same device is harmless: the\n---truncated---(CVE-2026-81001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxdp: fix zero-copy frame layout\n\nxdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page\nand advertises PAGE_SIZE as its frame size. It allows the copied frame\nto occupy the page tail needed by skb_shared_info and records zero\nheadroom even when metadata separates the frame header from packet data.\nAn AF_XDP zero-copy packet redirected through cpumap can therefore make\nthe skb overlap skb_shared_info or place it beyond the allocated page.\n\nLimit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the\nmetadata length in frame headroom. Redirect callers already handle a\nNULL conversion result.\n\nBUG: KASAN: slab-out-of-bounds in skb_gro_receive\nWrite of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146\nCall Trace:\n skb_gro_receive (net/core/gro.c:174)\n udp_gro_receive (net/ipv4/udp_offload.c:812)\n inet_gro_receive (net/ipv4/af_inet.c:1539)\n dev_gro_receive (net/core/gro.c:515)\n gro_receive_skb (net/core/gro.c:633)\n cpu_map_kthread_run (kernel/bpf/cpumap.c:395)\n kthread (kernel/kthread.c:436)\n ret_from_fork (arch/x86/kernel/process.c:164)\n ret_from_fork_asm (arch/x86/entry/entry_64.S:255)\nKernel panic - not syncing: KASAN: panic_on_warn set ...(CVE-2026-81002)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Force requesting ACS when tboot is enabled\n\nCurrently the conditions of requesting ACS in detect_intel_iommu()\ndon\u0026apos;t include tboot, leading to a possible misconfiguration with ACS\ndisabled (e.g. due to user opts) while iommu is later forced on by\ntboot_force_iommu().\n\nFix it by checking tboot in detect_intel_iommu().(CVE-2026-89448)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: Fix CT limit teardown use-after-free\n\nPacket processing uses CT limit state under RCU, while netns teardown\nfrees that state under ovs_mutex. The CT limit pointer was neither removed\nfrom readers nor protected by a grace period, allowing packet processing to\ndereference the freed state.\n\nAn unprivileged user can trigger this bug from a user and network\nnamespace, causing a slab-use-after-free in ovs_ct_execute() when the\nnetns is torn down.\n\nPublish the CT limit pointer through RCU, remove it before teardown, and\nwait for readers before freeing its contents. Keep ovs_mutex around\nindividual CT limit updates, and use the RCU read-side lock while GET\ntraverses the RCU-protected limit lists.\n\nNetns teardown detaches the RCU-protected CT limit state in the pernet\n.pre_exit callback while holding ovs_mutex. The pernet core guarantees an\nRCU grace period between the .pre_exit and .exit callbacks, so the .exit\ncallback completes the teardown without adding any extra synchronization.\n\nThe netlink command handlers do not need NULL checks because the userspace\nnetlink socket holds an active reference to its network namespace while a\nrequest is processed. The per-netns exit path therefore cannot run\nconcurrently with SET, DEL, or GET for that socket\u0026apos;s namespace.(CVE-2026-89488)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsvcrdma: Reject Read lists that exceed the page budget\n\nIndividual Read segment lengths are validated at decode time, but\nnothing prevents a requester from sending multiple segments whose\ncumulative length exceeds the rq_pages array budget. When one\nsegment fills the page array exactly, the runtime guard in\nsvc_rdma_build_read_segment() is bypassed because len reaches zero.\nA subsequent segment then accesses the NULL sentinel slot at\nrq_pages[rq_maxpages], resulting in a NULL pointer dereference during\nDMA mapping.\n\nAccumulate pages across all Read segments and reject the message at\ndecode time when the total would overflow the page budget.(CVE-2026-89528)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsvcrdma: Reject inline replies that overflow the pull-up buffer\n\nAn RPC-over-RDMA client can request a reply, such as an NFS READ\npayload, without providing a Write list or a Reply chunk to carry\nit. When such a reply needs more scatter/gather entries than the\ndevice\u0026apos;s Send Queue supports, svc_rdma_pull_up_needed() selects\npull-up and svc_rdma_pull_up_reply_msg() linearizes the whole\nreply into sctxt-\u0026gt;sc_xprt_buf. That buffer is only sc_max_req_size\nbytes, while the reply on this path is bounded only by the client\u0026apos;s\nrequest, so svc_rdma_xb_linearize() copies past the end of the\nbuffer and corrupts adjacent slab memory. The oversized length is\nthen stored in sc_sges[0].length and posted, so the device also\nreads beyond the mapped region.\n\nThe SGE-exhaustion branch is the only pull-up path that can exceed\nthe buffer: the threshold branch pulls up only replies smaller\nthan RPCRDMA_PULLUP_THRESH, and replies that fit the device\u0026apos;s SGE\nbudget are sent directly without linearization. Make\nsvc_rdma_pull_up_needed() report -E2BIG when the reply it would\npull up cannot fit sc_max_req_size, and fail the request with\nERR_CHUNK as RFC 8166 Section 4.5.3 directs rather than dropping\nthe connection.\n\nThe helper no longer answers a simple yes/no question: it now\nreports pull-up, no pull-up, or -E2BIG for a reply too large to\nlinearize. Rename svc_rdma_pull_up_needed() to\nsvc_rdma_check_pull_up() so its name no longer implies a boolean\npredicate.(CVE-2026-89530)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: fix gssx_dec_option_array error path bugs\n\nFour coupled defects in the gssx XDR option-array decoder make the\nerror paths unsafe: a NULL deref in the caller, a refcount leak on\nthe decoded group_info, and a latent use-after-free that the leak\nfix would otherwise expose.\n\ngssx_dec_option_array() sets oa-\u0026gt;count = 1 before allocating\noa-\u0026gt;data. If that allocation fails, -ENOMEM is returned with\noa-\u0026gt;count == 1 and oa-\u0026gt;data == NULL. All other error paths jump\nto free_oa: which frees oa-\u0026gt;data and NULLs it but also leaves\noa-\u0026gt;count == 1. The caller trusts the count:\n\n gssp_accept_sec_context_upcall()\n gssx_dec_accept_sec_context()\n gssx_dec_option_array() /* fails, count=1 data=NULL */\n data = res.options.data[0].value /* NULL deref */\n\nIndependently, free_creds: releases the partially decoded svc_cred\nwith a bare kfree(creds). gssx_dec_linux_creds() installs a\ngroups_alloc() result into creds-\u0026gt;cr_group_info; that object is\nkvmalloc-backed and refcounted, and only put_group_info() reaches\nkvfree(). A plain kfree(creds) drops the wrapper and leaks the\ngroup_info allocation.\n\nThe natural fix for the leak is to call free_svc_cred(creds) before\nkfree(creds), but free_svc_cred() invokes put_group_info() on\ncreds-\u0026gt;cr_group_info unconditionally when non-NULL. The existing\nout_free_groups: path in gssx_dec_linux_creds() already called\ngroups_free() on that pointer without clearing it, so once\nfree_svc_cred() is wired in, the subsequent put_group_info() would\ntouch freed memory.\n\nFix all four together:\n\n - Move the oa-\u0026gt;count = 1 assignment below the oa-\u0026gt;data allocation\n so it is never set when oa-\u0026gt;data is NULL.\n - Reset oa-\u0026gt;count to 0 at free_oa: so count and data stay\n coherent and the caller sees an empty option array.\n - Call free_svc_cred(creds) before kfree(creds) at free_creds:\n so the refcounted cr_group_info is released. free_svc_cred()\n either NULL-guards each field explicitly (cr_group_info has\n an if() check) or delegates to a helper that is NULL-safe\n itself (kfree for the string fields, gss_mech_put() which\n guards with if(gm) at gss_mech_switch.c:342), so it is safe\n to call on a partially decoded svc_cred where only\n cr_uid/cr_gid/cr_group_info have been written and everything\n else is zero from kzalloc.\n - In gssx_dec_linux_creds()\u0026apos;s out_free_groups: path, release\n cr_group_info with put_group_info() rather than groups_free()\n so the teardown matches free_svc_cred()\u0026apos;s refcount-aware path,\n and clear the pointer so a later free_svc_cred() on the same\n creds does not release it a second time.(CVE-2026-89544)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: defer rq_argp and rq_resp free until after RCU grace period\n\nsvc_rqst_free() frees rqstp-\u0026gt;rq_argp and rqstp-\u0026gt;rq_resp synchronously\nvia kfree(), but defers the rqstp struct free via kfree_rcu(). After\nsvc_exit_thread() calls list_del_rcu() and svc_rqst_free(), there is\na window where RCU readers that started before list_del_rcu() can still\ntraverse the thread list and find the rqstp. These readers (e.g.\nnfsd_nl_rpc_status_get_dumpit()) dereference rqstp-\u0026gt;rq_argp, which has\nalready been freed \u2014 a use-after-free.\n\nFix this by moving the kfree of rq_argp and rq_resp into an explicit\ncall_rcu() callback alongside the struct free. Resources not accessed\nby RCU readers (bvec, buffer pages, scratch folio, auth_data) remain\nsynchronously freed.(CVE-2026-89545)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction\n\nmptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce,\nbackup, join_id, token and msk from the saved cookie entry when rebuilding\nthe request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it\ndoes not restore local_id, even though the SYN path saved it.\nsubflow_ulp_clone() then reads that uninitialized field and stores it as\nthe joined subflow\u0026apos;s address-ID. Because the request-sock slab is\nSLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale\nbyte of a previously freed request socket, which an off-path peer can\ninfluence by sending concurrent MP_JOIN SYNs. This corrupts the path\nmanager\u0026apos;s id-based subflow bookkeeping for the connection.\n\nRestore subflow_req-\u0026gt;local_id from the cookie entry, as done for the other\nfields.(CVE-2026-89554)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix UAF in check_new_map() on session freed during unlock\n\ncheck_new_map() iterates mdsc-\u0026gt;sessions[] and for each active session\ndrops mdsc-\u0026gt;mutex to perform per-session operations. The forced-close\npath (rank removed from map) correctly takes a reference on s via\nceph_get_mds_session() before releasing mdsc-\u0026gt;mutex, but three other\npaths do not:\n\n Path A (address changed): mutex_unlock \u2192 mutex_lock(\u0026amp;s-\u0026gt;s_mutex)\n Path B (reconnect): mutex_unlock \u2192 send_mds_reconnect(mdsc, s)\n Path C (active transition): mutex_unlock \u2192 mutex_lock(\u0026amp;s-\u0026gt;s_mutex)\n\nWithout the extra reference, another thread can acquire mdsc-\u0026gt;mutex\nduring the unlock window, call __unregister_session() which drops the\nlast reference on s, and free it. The original thread then accesses\nfreed memory via s-\u0026gt;s_mutex.\n\nFix by adding ceph_get_mds_session(s) before each mutex_unlock and\nceph_put_mds_session(s) after the corresponding mutex_lock, matching\nthe pattern already used in the forced-close path.\n\nRace timeline (Path A):\n\n Thread A (check_new_map) Thread B (another map update\n holds mdsc-\u0026gt;mutex or session teardown)\n -------------------------- --------------------------\n s = mdsc-\u0026gt;sessions[i]\n (refcount == 1, held only by\n sessions[] array)\n\n mutex_unlock(\u0026amp;mdsc-\u0026gt;mutex)\n ---\u0026gt; acquires mdsc-\u0026gt;mutex\n __unregister_session(mdsc, s)\n sessions[i] = NULL\n ceph_put_mds_session(s)\n refcount: 1 -\u0026gt; 0\n kfree(s) \u0026lt;--- freed!\n\n mutex_lock(\u0026amp;s-\u0026gt;s_mutex)\n UAF on freed s-\u0026gt;s_mutex(CVE-2026-89654)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Prevent lock owner use-after-free during client teardown\n\n__destroy_client() releases a client\u0026apos;s open owners, but a lock owner\nwhose only reference is a blocked lock (nbl) stays on\ncl_ownerstr_hashtbl. client_has_state() does not count a bare owner,\nso DESTROY_CLIENTID can reach __destroy_client() with such owners\npresent.\n\n__destroy_client() then walks the table, calling remove_blocked_locks()\non each owner without a reference. Freeing a blocked lock drops the\nowner reference held via flc_owner. The per-net laundromat reaps\nblocked locks from nn-\u0026gt;blocked_locks_lru independently of client state.\nThe two paths share blocked_locks_lock only for the list splice, not\nthe owner\u0026apos;s lifetime. The laundromat therefore frees the owner as\n__destroy_client() dereferences it, a NULL dereference in\nremove_blocked_locks().\n\nnfsd4_release_lockowner() holds a reference across the same call;\n__destroy_client() does not. Hold cl_lock across the walk, taking a\nreference and unhashing each owner, then drop it before\nremove_blocked_locks() and nfs4_put_stateowner(), which take\nblocked_locks_lock and cl_lock.(CVE-2026-89662)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE\n\nThe NFSv2 sattr decoder converts the wire useconds to nanoseconds in\nsvcxdr_decode_sattr():\n\n\tiap-\u0026gt;ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC;\n\ntmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in\nunsigned long. On ILP32 that is 32 bits, and an out-of-range useconds\nvalue such as 4294968 wraps to tv_nsec == 704. The corruption therefore\nhappens during decode, before any proc function can inspect the value,\nand a later range check on tv_nsec would see an in-range result and\naccept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply.\nNFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return\nfor a malformed time argument, and the check cannot move to the proc\nfunction the way the v3/v4 nsec range checks do.\n\nGuard the raw useconds before the multiplication and reject values\ngreater than 1000000. useconds == 1000000 is kept: it is the Sun\nconvention for \u0026quot;set to the current server time\u0026quot;, and the in-tree Linux\nNFSv2 client emits it in both the atime and the mtime field for a plain\ntouch / utimes(file, NULL) (see encode_sattr() and\nxdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000\nwould turn that common operation into a hard decode failure for both\nSETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap\non ILP32, so the Sun convention value passes through safely. Only\ngenuinely out-of-range values (\u0026gt; 1000000) are rejected. The atime and\nmtime guards are therefore symmetric.\n\nThe decoder only applied the Sun convention in the mtime block, which\nclears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a\nclient puts 1000000 in the atime field but not in the mtime field, the\natime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET\nset, so the bogus value reached the filesystem. Apply the convention in\nthe atime block as well, clearing ATTR_ATIME_SET so the server uses its\ncurrent time and ignores the value. Only ATTR_ATIME_SET is cleared there.\nThe mtime block keeps its existing behavior, where 1000000 means \u0026quot;set\nboth atime and mtime to now\u0026quot;.\n\n[ cel: various tweaks, addenda, and clean-ups ](CVE-2026-89665)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: reject out-of-range nseconds in NFSv3 SETATTR and create ops\n\nA client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD\ncarrying an atime or mtime whose nseconds field is out of range. The\nvalue is well-formed on the wire and decodes cleanly into a valid\nuint32, but it is not a valid timespec64: tv_nsec must be less than\nNSEC_PER_SEC.\n\nNothing in the setattr path clamps it. notify_change() runs the time\nthrough timestamp_truncate(), which does not reduce tv_nsec below\nNSEC_PER_SEC when the filesystem supports nanosecond granularity\n(s_time_gran == 1), and the inode atime/mtime setters store it verbatim\n(only ctime is normalized, via inode_set_ctime_to_ts()). The\nun-normalized value then corrupts on-disk metadata: ext4\u0026apos;s\next4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, which\noverflows the 32-bit extra field and clobbers the seconds-epoch bits, so\nthe stored seconds (and thus the year) are wrong on read-back. XFS with\nbigtime mis-stores the timestamp for the same reason.\n\nValidate the client-supplied atime/mtime in the proc handlers and return\nNFS3ERR_INVAL before anything is changed. RFC 1813 lists NFS3ERR_INVAL\nfor SETATTR and describes it as the error for a value the server \u0026apos;can\nnot store ... in its own representation\u0026apos;; the client maps it to EINVAL.\n\nChecking in the proc handlers, rather than in nfsd_setattr(), keeps the\nrejection in front of object creation. The create operations create the\nobject before nfsd_create_setattr() runs, so a late failure would leave\nthe new object behind and turn a non-idempotent request into a namespace\nchange that reports failure. The check is therefore done up front, for\nthe create operations before the object is created.\n\ntv_nsec is a long, so the comparison casts it to unsigned long (the same\nwidth) rather than to u32, matching timespec64_valid(). A u32 cast would\ntruncate on 64-bit; the unsigned long cast also rejects a value that\nbecame negative when an out-of-range u32 wire nseconds was assigned to a\n32-bit long.\n\nOnly client-supplied times are checked: SET_TO_SERVER_TIME requests\ncarry no client value. The sattrguard3 ctime is deliberately left alone:\nan out-of-range guard simply never matches the object\u0026apos;s ctime and yields\nNFS3ERR_NOT_SYNC via the existing guardtime comparison, which is the\nprotocol-correct outcome rather than rejecting the request.(CVE-2026-89666)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: initialize copy-notify stateid before publishing it\n\nnfsd4_copy_notify() finished initializing the cpntf state after\nnfs4_alloc_init_cpntf_state() had already linked it into the\ns2s_cp_stateids IDR and the parent\u0026apos;s sc_cp_list, with cs_count == 1 (the\nmembership reference) and none held for the caller. A racing\nOFFLOAD_CANCEL (crafted cl_id == nn-\u0026gt;s2s_cp_cl_id plus the guessable\nso_id) could reach manage_cpntf_state() and free the entry, turning the\ncaller\u0026apos;s subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid\nwrites into use-after-free. The owning clientid was also only recorded\nafter publication, so it could not gate an ownership check in that window.\n\nRecord cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state()\nbefore nfs4_init_cp_state() publishes the entry, and return it with an\nextra reference. The caller reads the stateid under that reference and\ndrops it with nfs4_put_cpntf_state(); on a late error the laundromat\nreaps the entry.(CVE-2026-89669)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: gate nfs3 setacl by argp-\u0026gt;mask\n\nnfsd3_proc_setacl() calls set_posix_acl() unconditionally for both\nACL_TYPE_ACCESS and ACL_TYPE_DEFAULT, passing argp-\u0026gt;acl_access and\nargp-\u0026gt;acl_default verbatim. The NFSv3 ACL decoder only populates\nthose pointers when the corresponding mask bit is set:\n\n nfs3svc_decode_setaclargs()\n if (args-\u0026gt;mask \u0026amp; NFS_ACL) decode into acl_access\n if (args-\u0026gt;mask \u0026amp; NFS_DFACL) decode into acl_default\n /* otherwise the pointer stays NULL (pc_argzero) */\n\n nfsd3_proc_setacl()\n set_posix_acl(.., ACL_TYPE_ACCESS, argp-\u0026gt;acl_access)\n set_posix_acl(.., ACL_TYPE_DEFAULT, argp-\u0026gt;acl_default)\n\nset_posix_acl(idmap, dentry, type, NULL) is the VFS \u0026quot;remove this\nACL type\u0026quot; operation. A NULL pointer that means \u0026quot;the client did not\nsend this arm\u0026quot; is therefore indistinguishable from \u0026quot;the client\nasked to remove this ACL\u0026quot;. A SETACL with mask=NFS_ACL silently\ndrops the directory\u0026apos;s default ACL; mask=0 drops both.\n\nThe sibling nfsd3_proc_getacl() already consults argp-\u0026gt;mask before\ntouching each arm; mirror that in setacl.\n\nFix by wrapping each set_posix_acl() call in the matching mask bit\ncheck and initializing error to 0 before inode_lock so that a\nrequest with neither bit set leaves the on-disk ACLs untouched and\nreturns nfs_ok. The out_drop_lock path and the unconditional\nposix_acl_release() at out: are preserved; both NULL-tolerate the\nskipped arms.(CVE-2026-89671)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget\n\nThe XDR buffer size calculation in nfsd4_ff_encode_layoutget() has\nmultiple errors that can result in either an out-of-bounds write or\nleaking uninitialized kernel memory to the client:\n\n - fh_len doesn\u0026apos;t account for XDR padding on the file handle data\n - uid and gid lengths use \u0026quot;8 + len\u0026quot; but xdr_encode_opaque() actually\n writes \u0026quot;4 + xdr_align_size(len)\u0026quot; bytes\n - ds_len omits the flags and stats_collect_hint fields (8 bytes),\n while len\u0026apos;s header constant overestimates by 8 bytes -- these\n partially cancel but leave a net mismatch\n\nThe worst case occurs with short strings (e.g. uid=0, gid=0 with an\nodd-sized file handle), where the function writes up to 5 bytes past\nthe reserved XDR buffer. Conversely, when string lengths happen to be\n4-byte aligned, the reservation is too large and stale buffer content\nis sent to the client.\n\nFix this by breaking out every encoded field explicitly in the ds_len\ncalculation, using xdr_align_size() for all variable-length opaque\nfields, and correcting the header constants.(CVE-2026-89674)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix UAF in async copy cancel and shutdown\n\nAn async copy could be freed or used after free while a teardown caller\n(OFFLOAD_CANCEL, nfsd4_shutdown_copy, nfsd4_cancel_copy_by_sb) raced the\ncopy kthread:\n\n - find_async_copy() bumped copy-\u0026gt;refcount but left the copy on\n clp-\u0026gt;async_copies, so the reaper\u0026apos;s cleanup_async_copy() could run\n release_copy_files() concurrently with a cancel/shutdown caller. Both\n put and NULL nf_src/nf_dst without a common lock, double-putting the\n nfsd_file and freeing it early.\n\n - nfsd4_do_async_copy() set NFSD4_COPY_F_STOPPED before its final uses\n of the copy (nfsd_update_cmtime_attr() on copy-\u0026gt;nf_dst,\n nfsd4_send_cb_offload()). nfsd4_stop_copy() treats a set STOPPED bit\n as \u0026quot;kthread done, skip kthread_stop()\u0026quot;, so a teardown caller ran\n release_copy_files() -- which puts and NULLs nf_dst -- while the\n kthread still dereferenced it (NULL/UAF).\n\n - copy-\u0026gt;copy_task was never pinned. The one-shot kthread self-reaps on\n return, so kthread_stop()\u0026apos;s get_task_struct() could touch a freed\n task_struct.\n\n - co_cb is embedded in the copy, but nfsd4_send_cb_offload() held a\n reference only on the client, so a concurrent teardown could free\n the copy while the CB_OFFLOAD callback was in flight.\n\nFix the teardown lifetime as a whole:\n\n - find_async_copy() unlinks the copy (clear cp_clp, list_del_init)\n under async_lock; the cancel, shutdown, and sb-cancel paths drop the\n list-membership reference via nfs4_put_copy() after nfsd4_stop_copy().\n Drop the now-redundant list_del fixup from cleanup_async_copy().\n\n - Because unlinking hides the copy from the reaper, its\n cleanup_async_copy() can no longer remove the copy\u0026apos;s s2s_cp_stateids\n entry; the cancel/shutdown/sb-cancel paths now call\n nfs4_free_copy_state() themselves (while cp_clp is still valid) so\n the entry does not dangle at freed memory for the laundromat and\n manage_cpntf_state() to dereference.\n\n - Give the kthread its own reference, taken in nfsd4_copy() before\n wake_up_process() and dropped at the end of nfsd4_do_async_copy();\n call wake_up_process() before list_add().\n\n - Pin the task_struct with get_task_struct() in nfsd4_copy(), released\n in nfs4_put_copy(), so kthread_stop() is safe whenever the kthread\n exits. Set NFSD4_COPY_F_STOPPED only in nfsd4_stop_copy(), which now\n always kthread_stop()s before release_copy_files(); completion is\n still reported via NFSD4_COPY_F_COMPLETED, so\n nfsd4_has_active_async_copies() is unaffected. Each teardown caller\n removes the copy from clp-\u0026gt;async_copies first, so kthread_stop() runs\n exactly once.\n\n - Take a copy reference in nfsd4_send_cb_offload(), dropped in\n nfsd4_cb_offload_release(). The kthread still holds its own reference\n there, so the refcount_inc() cannot race the final free.\n\n - Read cp_clp with smp_load_acquire() to pair with the unordered\n set_bit()/clear_bit() writers (Documentation/atomic_bitops.rst).(CVE-2026-89675)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix nfsd_file leak on inter-server COPY setup failure\n\nWhen nfsd4_setup_inter_ssc() fails, nfsd4_copy() returns\nnfserr_offload_denied directly, bypassing the out: label where\nrelease_copy_files() would drop the nf_dst reference taken by\nnfs4_preprocess_stateid_op(). Each failed inter-server COPY\nleaks one nfsd_file, pinning file/inode/dentry/vfsmount.\n\nFix by setting status and jumping to out: instead of returning\ndirectly.(CVE-2026-89680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix clock domain mismatch in clients_still_reclaiming()\n\nclients_still_reclaiming() computes a deadline from nn-\u0026gt;boot_time\n(CLOCK_REALTIME, ~1.7 billion) but compares it against\nktime_get_boottime_seconds() (CLOCK_BOOTTIME, seconds since boot).\nThe comparison is always false \u2014 it would take ~54 years of uptime\nfor BOOTTIME to exceed the REALTIME-derived deadline.\n\nThis means any client can hold the server in grace indefinitely by\nsending CLAIM_PREVIOUS OPEN requests, blocking all non-reclaim\noperations for all other clients.\n\nAdd boot_time_bt (CLOCK_BOOTTIME) alongside the existing boot_time\nand use it for the deadline computation. boot_time (CLOCK_REALTIME)\nis preserved for its cl_boot clientid-nonce role.(CVE-2026-89685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref\n\nWhen CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return\nsuccess with fh_dentry and fh_export both NULL if fh_verify() returns\nnfserr_stale and putfh-\u0026gt;no_verify is true. The NFSD4_FH_FOREIGN flag\nis set, but the compound dispatch loop only uses this flag to bypass\nthe nfserr_nofilehandle check -- it does not prevent subsequent ops\nfrom running with a NULL fh_dentry.\n\nA remote client can exploit this by crafting a COMPOUND that includes\nan inter-SSC COPY (which causes check_if_stalefh_allowed() to set\nno_verify=true on the saved PUTFH) with an additional op inserted\nbetween the source PUTFH and SAVEFH. For example, SETATTR calls\nfh_want_write() which dereferences fh_export-\u0026gt;ex_path.mnt without\ncalling fh_verify() first, causing a NULL pointer dereference in the\nnfsd kthread.\n\nFix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set\nand fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow)\nand ops with ALLOWED_WITHOUT_FH (which don\u0026apos;t need a resolved\nfilehandle) may proceed. All other ops receive nfserr_stale, per\nRFC 7862 Section 15.2.3 which specifies that foreign filehandle\nvalidation is deferred to the consuming operation and NFS4ERR_STALE\nreturned at that point.(CVE-2026-89696)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlockd, nfsd: RCU-protect nlmsvc_ops dispatch\n\nnlmsvc_ops is published by nfsd_lockd_init() and cleared by\nnfsd_lockd_shutdown() with plain stores, while lockd dereferences\nit unguarded from dispatch sites in fs/lockd/svcsubs.c. The pointer\ntargets nfsd\u0026apos;s .rodata and the fopen/fclose callbacks live in nfsd\u0026apos;s\n.text, so a stale load after rmmod nfsd results in either a NULL\nderef or a module-text use-after-free.\n\nDeclare nlmsvc_ops as __rcu, publish via rcu_assign_pointer(), clear\nvia RCU_INIT_POINTER() + synchronize_rcu(). Add a struct module\n*owner field to nlmsvc_binding and pin the module across indirect\ncalls with try_module_get/module_put. When the binding is torn down,\nfall back to fput() to avoid leaking struct file references.(CVE-2026-89709)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Initialize NVMe abort_work once at submission\n\nqla_nvme_fcp_abort() and qla_nvme_ls_abort() ran INIT_WORK() on\npriv-\u0026gt;abort_work immediately before schedule_work(). INIT_WORK()\nreinitializes the work_struct, resetting its list head and clearing the\npending bit. If an abort is issued more than once for the same command\n(for example, concurrent transport teardown and a timeout-driven abort),\nthe second INIT_WORK() reinitializes a work item that is already queued,\nwhich can corrupt the workqueue list and lead to crashes or a looping\nworker.\n\nInitialize priv-\u0026gt;abort_work once at command submission, next to the\nexisting per-command spin_lock_init(\u0026amp;priv-\u0026gt;cmd_lock), and leave only\nschedule_work() in the abort paths. schedule_work() already does nothing\nwhen the work item is still pending, so a repeated abort no longer\ndisturbs an in-flight work item. The command is not returned to the\ntransport until the final kref_put()/release callback runs after\nabort_work has completed, so the work item is idle before priv is reused\nand the single submission-time INIT_WORK() is safe.(CVE-2026-89860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4.2: fix LAYOUTSTATS send buffer exhaustion\n\nencode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE),\ni.e. 256 bytes, for the layoutupdate4 body written by the layout driver.\nThe flexfiles record can exceed that.\n\nff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4,\nan nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server\nwhose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of\nthose bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4\nand the bool add a further 144, so the body passes 256 bytes before the\nnetaddr4 is encoded at all. encode_layoutstats() additionally writes\nthe deviceid4 and the layoutupdate4 lou_type word, neither of which the\nmacro accounts for.\n\nThe filehandle and the address are both chosen by the server, through\nLAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the\nend of the send buffer. xdr_reserve_space() returns NULL once that\nhappens, and the two ff_layout_encode_io_latency() calls run with\ndss_info-\u0026gt;mirror-\u0026gt;lock held, so a NULL return there leaves the lock\npermanently held.\n\nRaise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the\nreservation.(CVE-2026-90103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt76x02: do not WARN on invalid rx descriptor length\n\nThe MPDU length in the rx descriptor comes from the hardware. In\nmonitor mode with the fcsfail filter enabled, the hardware passes up\ncorrupted frames, and a corrupted frame can report a length larger\nthan the received buffer. The bounds check correctly discards such\nframes, but its WARN_ON_ONCE wrapper means any over-the-air garbage\nframe taints the kernel, and panics it on the first such frame when\npanic_on_warn is set.\n\nDrop the WARN and discard the frame silently, matching what\ncommit c2d4c8723dbf (\u0026quot;mt76x2: remove some harmless WARN_ONs in tx\nstatus and rx path\u0026quot;) did for the neighboring rx and tx status paths.\n\nObserved immediately on rx with an MT7612U in fcsfail monitor mode\non a busy channel.(CVE-2026-90382)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/xive: propagate IPI init errors to prevent use-after-free\n\nWhen xive_init_ipis() fails (e.g. irq_domain_alloc_irqs() fails),\nthe error path frees the global xive_ipis array. However,\nxive_smp_probe() previously ignored this failure and proceeded to\ncall xive_setup_cpu_ipi(), which dereferences the already-freed\nxive_ipis pointer -- a use-after-free.\n\nNow that xive_smp_probe() returns int (previous patch), propagate\nthe error from xive_init_ipis() and xive_setup_cpu_ipi() through\nxive_smp_probe(). Check the return value in both pnv_smp_probe()\nand pSeries_smp_probe() so that IPI setup is aborted cleanly on\nfailure, avoiding the use-after-free.(CVE-2026-93260)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix addr_filter_ranges lifetime\n\nLee Jia Jie reported that since event::addr_filter_ranges is used\nunder RCU, it should be RCU freed.(CVE-2026-93817)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hidpp: fix potential UAF in hidpp_connect_event()\n\nIf input_register_device() fails, we call input_free_device(), but keep\nstale pointer to the old device in hidpp-\u0026gt;input, which could potentially\nlead to UAF. Fix that by resetting it to NULL before returning from\nhidpp_connect_event().(CVE-2026-93826)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: add boundary checks in two places\n\nAdd boundary checks in acpi_ps_get_next_namestring() and\nacpi_ps_peek_opcode() to prevent out-of-bounds access.(CVE-2026-97444)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources()\n\nEnhance buffer validation in acpi_ut_walk_aml_resources() to prevent\nbuffer overflows.(CVE-2026-97445)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Add validation for node in acpi_ns_build_normalized_path()\n\nAdd validation for node in acpi_ns_build_normalized_path()\nto prevent use-after-free vulnerabilities.(CVE-2026-97448)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: validate handler object type in two places\n\nACPICA: validate handler object type in acpi_ev_has_default_handler()\nand acpi_ev_find_region_handler().(CVE-2026-97450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op)\n\nAdd overflow check for Index + Length to prevent integer overflow\nwhen calculating the truncation length. This prevents negative\nsize parameter being passed to memcpy().(CVE-2026-97451)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Prevent adding invalid references\n\nPrevent adding references for local, argument, and debug objects\nin acpi_ut_copy_simple_object().(CVE-2026-97452)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: add boundary checks in acpi_ps_get_next_field()\n\nAdd boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds\naccess.(CVE-2026-97454)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Fix use-after-free in acpi_ds_terminate_control_method()\n\nFix use-after-free issue in acpi_ds_terminate_control_method() by\nclearing references to method locals and arguments.(CVE-2026-97455)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Skip vport under deletion in report ID acquisition\n\nqla24xx_report_id_acquisition() format-1 handling walks ha-\u0026gt;vp_list under\nvport_slock, takes a vref_count on the matching vport and calls\nqla_update_host_map() to register its port id.\n\nA vport teardown via qla24xx_vport_delete() sets VPORT_DELETE, then\nqla24xx_disable_vp() removes the vport from the host_map btree and zeroes\nvha-\u0026gt;d_id (RESET_AL_PA). The vport is only unlinked from vp_list later,\nin qla24xx_deallocate_vp_id(), which clears vp_map[idx] (RESET_VP_IDX)\nbut does not touch host_map. In the window in between, report ID\nacquisition can still find the vport on vp_list and call\nqla_update_host_map(); with d_id already zeroed it takes the\nbtree_insert32() path and re-inserts the dying vport into host_map.\nNothing cleans that entry afterwards, so once scsi_host_put() frees the\nvha a later host_map lookup dereferences freed memory.\n\nSkip a vport that has VPORT_DELETE set before taking the reference, so it\nis neither re-registered nor scheduled for DPC re-registration. This\nmirrors the existing guard in qla2x00_alert_all_vps().(CVE-2026-97531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix use-after-free of qpair work on queue teardown\n\nThe response queue MSI-X handler qla2xxx_msix_rsp_q() schedules\nqla_do_work() via queue_work(ha-\u0026gt;wq, \u0026amp;qpair-\u0026gt;q_work). qla_do_work()\ndereferences the qpair (vha, rsp) and takes qpair-\u0026gt;qp_lock.\n\nDuring teardown, qla2xxx_delete_qpair() deletes the response queue, which\ncalls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and\nthe qpair. free_irq() waits for running hardirq handlers but does not\ncancel work already placed on ha-\u0026gt;wq. A still-pending q_work then runs\nqla_do_work() against the freed qpair and response queue, causing a\nuse-after-free. This is especially likely during full adapter teardown,\nwhere destroy_workqueue(ha-\u0026gt;wq) forces pending work to run after the queue\npairs have been freed.\n\nFlush the work item with cancel_work_sync() in qla25xx_free_rsp_que()\nafter free_irq() has released the interrupt (so no new work can be\nqueued) and before the response queue and qpair memory are freed (so the\nflushed handler still sees valid memory). Guard on rsp-\u0026gt;qpair and ha-\u0026gt;wq\nto match the INIT_WORK() condition and avoid operating on an\nuninitialized work_struct.(CVE-2026-97536)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l2-ctrls: validate HEVC tile counts\n\nThe stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from\ncolumn_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[]\nand use them as tile-loop bounds, but std_validate_compound() does not\nbound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling\nenabled whose tile counts exceed the uAPI array capacity, mirroring the\nexisting compound-control range checks.(CVE-2026-97576)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: mpls: clear inner_protocol when the last label is popped\n\nskb_mpls_push() records the pre-encapsulation network header once, gated\non !skb-\u0026gt;inner_protocol. skb_mpls_pop() never clears that record, so it\noutlives the encapsulation it describes.\n\nOpen vSwitch can then re-push MPLS onto a packet whose\ninner_network_header still points at the older, deeper offset: push a\nlabel, pop every label, recirculate (ovs_flow_key_update() re-derives\nkey-\u0026gt;eth.type and resets network_header, but leaves inner_*), then push\nagain. ovs_fragment() trusts the record:\n\n\tskb-\u0026gt;network_header = skb-\u0026gt;inner_network_header;\n\nso skb_network_offset() goes negative. The bound check is signed:\n\n\tif (skb_network_offset(skb) \u0026gt; MAX_L2_LEN)\n\na negative offset passes it, and prepare_frag() widens the value:\n\n\tunsigned int hlen = skb_network_offset(skb);\n\tmemcpy(\u0026amp;data-\u0026gt;l2_data, skb-\u0026gt;data, hlen);\n\nwhich is a ~4GiB memcpy out of a 30-byte per-CPU buffer.\n\nReproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8):\n\n BUG: unable to handle page fault for address: ffffe8ffffc16000\n #PF: supervisor write access in kernel mode\n Oops: 0002 [#1] SMP KASAN NOPTI\n RIP: 0010:memcpy+0x8/0x20\n RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000\n prepare_frag+0x3df/0x4e0\n ovs_fragment+0x589/0x7e0\n do_output+0x4ce/0x5e0\n do_execute_actions+0x55d2/0x7b30\n ovs_execute_actions+0xea/0x450\n\nSame root-cause shape as commit 975b5b067f52 (\u0026quot;ipv6: sr: restore network\nheader before routing and forwarding\u0026quot;): a stale network header offset\nreaching a consumer that widens it. Here it originates in the MPLS\npush/pop path.\n\nClear inner_protocol once the packet is no longer MPLS, so a later push\nre-records the current header. net/sched/act_mpls.c is the only other\nskb_mpls_pop() caller and gets the same fix; sch_frag.c saves and\nrestores inner_protocol around fragmentation in the same way OVS does.(CVE-2026-97612)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Set the trace clock before registering the histogram trigger\n\nhist_register_trigger() puts the trigger on the global named_triggers\nlist in cmd_ops-\u0026gt;init(), and only then sets the trace clock:\n\n\tif (data-\u0026gt;cmd_ops-\u0026gt;init) {\n\t\tret = data-\u0026gt;cmd_ops-\u0026gt;init(data);\n\t\tif (ret \u0026lt; 0)\n\t\t\tgoto out;\n\t}\n\n\tif (hist_data-\u0026gt;enable_timestamps) {\n\t\tret = tracing_set_clock(file-\u0026gt;tr, hist_data-\u0026gt;attrs-\u0026gt;clock);\n\t\tif (ret) {\n\t\t\thist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock));\n\t\t\tgoto out;\n\t\t}\n\nThe clock string is not checked anywhere before that call, so a named\ntrigger using common_timestamp with an unknown clock fails after it has\nalready become findable. event_hist_trigger_parse() then frees it\nwithout taking it off the list, and the next lookup by name reads the\nfreed object:\n\n ~# cd /sys/kernel/tracing/events/sched/sched_switch\n ~# echo \u0026apos;hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus\u0026apos; \u0026gt; trigger\n bash: echo: write error: Invalid argument\n ~# echo \u0026apos;hist:name=foo:keys=common_pid\u0026apos; \u0026gt; trigger\n\n BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0\n Read of size 8 at addr ffff88800915d760 by task init/1\n find_named_trigger+0xac/0xc0\n hist_register_trigger+0xc1/0x900\n event_hist_trigger_parse+0x3146/0x6af0\n event_trigger_write+0xce/0x160\n Freed by task 63:\n kfree+0x154/0x420\n trigger_kthread_fn+0xfd/0x160\n\nSet the clock before the trigger is registered, so that nothing which\ncan fail runs after it is published, the way commit 6f86bdeab633\n(\u0026quot;tracing: Fix bad hist from corrupting named_triggers list\u0026quot;) moved the\nregistration below the rest of the setup.\n\ntracing_set_filter_buffering() is reference counted, so the init failure\npath has to drop the reference that the clock block now takes first.(CVE-2026-97935)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix fib6 walker UAF on seq stop\n\nipv6_route_iter_active() treats a walker in FWS_U at the table root as\nalready unlinked. fib6_del_route() can move a still-linked walker into\nthat same state when the current leaf is the last route at the root,\nso ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq\nprivate object can then be freed while it remains on\nnet-\u0026gt;ipv6.fib6_walkers. A later route deletion walks the dangling list\nand uses the freed walker.\n\nUse the list head as membership state and reinitialize it when\nunlinking. Keep the existing w-\u0026gt;node check so a never-started iterator\nwith a zeroed private object is not treated as linked.\n\nThe same stop helper is used by /proc/net/ipv6_route and by the BPF\nipv6_route iterator. The BPF show path only widens the race.(CVE-2026-97940)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Don\u0026apos;t predict JMP32 pointer vs zero comparisons\n\nConsider the following program:\n\n r1 = map_value; /* low 32 bits are zero at runtime */\n r6 = 0xdead000000000000;\n if w1 != 0 goto l1;\n l0: r1 += r6;\n r2 = *(u64 *)(r1 + 0);\n exit;\n l1: r6 = 0;\n goto l0;\n\nAt the moment is_branch_taken() reports the jump as always taken,\nbecause it does not distinguish between BPF_JMP and BPF_JMP32\ncomparisons when processing \u0026apos;if w1 != 0 ...\u0026apos;.(CVE-2026-98041)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: remove stale namespaces by NSID range during scan\n\nnvme_scan_ns_list() drops the stale namespaces in each gap in the\nreported NSID list one NSID at a time. Every iteration calls\nnvme_find_get_ns() to look the namespace up and removes it if it is\npresent. The loop runs once per NSID in the gap rather than once per\nnamespace actually present.\n\nNSIDs are 32-bit, so a target with a sparse NSID space can make a\nsingle gap spin the loop billions of times with nothing to remove.\n\n watchdog: BUG: soft lockup - CPU#4 stuck for 26s!\n Workqueue: nvme-wq nvme_scan_work [nvme_core]\n RIP: 0010:__srcu_read_unlock+0xb/0x20\n Call Trace:\n nvme_find_get_ns+0x7d/0xb0 [nvme_core]\n nvme_scan_ns_list+0xe8/0x280 [nvme_core]\n nvme_scan_work+0x18a/0x280 [nvme_core]\n process_one_work+0x197/0x380\n worker_thread+0x2fe/0x410\n kthread+0xe0/0x100\n\nRename nvme_remove_invalid_namespaces() to nvme_remove_nsid_range()\nand give it an open (start, end) NSID range. ctrl-\u0026gt;namespaces is\nsorted by NSID, so the whole gap is dropped in a single walk that\nstops once end is reached. This bounds the work by the namespaces\nthat are present instead of by the size of the gap.(CVE-2026-98056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: sr: restore network header before routing and forwarding\n\nipv6_srh_rcv() runs with skb-\u0026gt;data at the Segment Routing Header (SRH)\nwhile skb_network_header() points at the IPv6 header.\n\nWhen segments_left \u0026gt; 0, ipv6_srh_rcv() previously restored the skb-\u0026gt;data\nposition by pushing sizeof(struct ipv6hdr), assuming the SRH immediately\nfollowed the fixed IPv6 header. If another extension header (such as a\nHop-by-Hop options header) precedes the SRH, skb_network_offset()\nremained negative.\n\nThis led to two problems:\n1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes\n __skb_flow_dissect() which passes the negative skb_network_offset()\n to flow dissection, breaking BPF and C flow dissector logic.\n2. If forwarded via ip6_forward() or redirected via act_mirred, downstream\n handlers (like sch_fragment() or neighbour output) pass the negative\n offset as an unsigned length, triggering OOB memcpy or buffer overflows.\n\nFix this by pushing -skb_network_offset(skb) before routing, ensuring\nskb_network_offset(skb) is 0 for route lookup / flow dissection as well as\ndownstream forwarding. On the loopback path, pull skb_transport_offset(skb)\nto restore skb-\u0026gt;data to the SRH before looping back.(CVE-2026-98096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan\n\nl2cap_new_connection() sets default value of channel mode to match the\nparent channel. l2cap_le_connect_req() left this at the default, and\ncreated L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that\nmode. This causes FLAG_DEFER_SETUP channels to reply to\nL2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect.\n\nIt can also result to stack OOB write (of l2cap_alloc_cid determined\nvalues) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not\nlimit maximum number of deferred channels or check for duplicate ident.\n\nFix by setting chan-\u0026gt;mode correctly in l2cap_le_connect_req().\n\nAlso check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE\ninstead of OOB write to make it less brittle.(CVE-2026-98108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: encrypted: fix integer overflow of datablob_len\n\nencrypted_key_alloc() stores datablob_len in a u16. It is computed from\nmultiple string and payload lengths. If the result exceeds U16_MAX, the\nassignment truncates the allocation size. KASAN reports a 32760-byte\nslab-out-of-bounds write when __ekey_init() copies the master key\ndescription into the undersized buffer.\n\nThe total payload length stored in key-\u0026gt;datalen is also a u16. Use\ncheck_add_overflow() to reject values that do not fit either destination,\nand use kzalloc_flex() for the flexible-array allocation.(CVE-2026-98222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: fix refcount bug in iwpm_get_nlmsg_request()\n\niwpm_get_nlmsg_request() initializes refcount _after_ list_add_tail()\nmaking it accessible to global list where another CPU can kref_get()\non nlmsg_request causing a refcount \u0026quot;addition on 0\u0026quot; bug. Fix this\nby initializing kref _before_ list_add_tail() so refcount for\nnlmsg_request can be incremented/decremented normally. In addition,\nalso initialize every field before list_add_tail().(CVE-2026-98252)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/ucma: Serialize join and leave on copy_to_user failure\n\nrdma_join_multicast() queues RoCE work that later reads the ucma_multicast\nthrough event-\u0026gt;param.ud.private_data, then list_add()s the CMA multicast\nat the head of id_priv-\u0026gt;mc_list. rdma_leave_multicast() matches only by\nsockaddr and destroys the first hit.\n\nucma_process_join() used to drop ctx-\u0026gt;mutex after a successful join and\nretake it only if copy_to_user() failed. Two concurrent JOIN_MCAST calls\nwith the same address can therefore insert a second CMA entry before the\nfirst thread\u0026apos;s leave. leave then cancels the newer work and the older\nworker still dereferences the ucma_multicast that the first thread frees.\n\nKeep ctx-\u0026gt;mutex held from rdma_join_multicast() through copy_to_user() and,\non -EFAULT, through rdma_leave_multicast() so leave cannot miss this join.\nDo not leave if join itself failed: that path never published this address\non mc_list, and a leave-by-addr would destroy an earlier successful join.(CVE-2026-98253)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: lock the socket in sock_gettstamp()\n\nsk-\u0026gt;sk_flags must only be changed while holding the socket lock,\nbecause sock_set_flag() and sock_reset_flag() use non atomic\noperations (__set_bit() and __clear_bit()).\n\nsock_gettstamp() is one of the last places where a bit of sk-\u0026gt;sk_flags\nis changed from a syscall without owning the socket lock, through\nsock_enable_timestamp(sk, SOCK_TIMESTAMP).\n\nsk_set_memalloc() and sk_clear_memalloc() also change sk-\u0026gt;sk_flags\nwithout the socket lock, but their callers (nbd, iscsi_tcp, nvme-tcp,\nsunrpc, wireguard) need a careful audit, this will be addressed in a\nseparate patch.\n\nJungwoo Lee and Wongi Lee reported an UDP socket use-after-free\ncaused by this bug: a SIOCGSTAMPNS_NEW ioctl racing with bind()\ncan cancel the SOCK_RCU_FREE bit that udp_lib_get_port() just set,\nbecause both threads perform a read-modify-write on the same word.\n\n CPU 0 (bind) CPU 1 (SIOCGSTAMPNS_NEW)\n -------------------------------- ----------------------------\n read sk_flags = F read sk_flags = F\n compute F | BIT(SOCK_RCU_FREE) compute F | BIT(SOCK_TIMESTAMP)\n store F | BIT(SOCK_RCU_FREE)\n sk_add_node_rcu(sk, ...)\n store F | BIT(SOCK_TIMESTAMP)\n\nAfter the lost update, SOCK_RCU_FREE is clear while the socket is\nvisible to lockless UDP receive lookups. sk_destruct() then frees\nthe socket immediately instead of waiting for a RCU grace period,\nwhile the receive path still holds a reference-less pointer to it:\n\n BUG: KASAN: slab-use-after-free in ipv4_pktinfo_prepare+0x30/0x410\n Read of size 8 at addr ffff888008806610 by task exploit/207\n CPU: 0 UID: 1000 PID: 207 Comm: exploit Not tainted 6.12.95+ #1\n ipv4_pktinfo_prepare+0x30/0x410\n udp_queue_rcv_one_skb+0x51c/0x1180\n udp_unicast_rcv_skb+0x109/0x350\n ip_protocol_deliver_rcu+0x14b/0x310\n ip_local_deliver_finish+0x29d/0x390\n ip_local_deliver+0x24d/0x2a0\n\nOnly grab the socket lock when SOCK_TIMESTAMP has to be set,\nto keep the common case lockless.(CVE-2026-98276)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/isert: wait for deferred control PDU completions before releasing the connection\n\nisert_send_done() hands ISTATE_SEND_TASKMGTRSP, ISTATE_SEND_REJECT and\nISTATE_SEND_TEXTRSP completions off to isert_comp_wq and returns. The work\nitem then runs isert_completion_put() -\u0026gt; isert_put_cmd(), which reads\nisert_conn-\u0026gt;conn and takes conn-\u0026gt;cmd_lock.\n\nNothing orders that work item against teardown. isert_wait_conn() queues\nisert_release_work, which frees isert_conn, and iscsit_close_connection()\nfrees the iscsit_conn right after it returns, so the queued work can run\nagainst freed memory.\n\nCount the deferred control PDU completions per connection and let\nisert_wait_conn() wait for them before the release work is queued.\n\nISTATE_SEND_LOGOUTRSP is deliberately not counted: that branch runs\niscsit_logout_post_handler(), which ends up waiting for\nconn-\u0026gt;conn_wait_comp, and that completion is only sent by\niscsit_close_connection() after it has called iscsit_wait_conn().\nWaiting for it here would deadlock. Its wait stays the existing\nisert_wait4logout().\n\nThe splat below is from a kernel with tracing printk()s and an msleep(200)\ninjected into isert_do_control_comp() to widen the window:\n\n BUG: KASAN: slab-use-after-free in isert_put_cmd+0x53d/0x620\n Read of size 8 at addr ffff8881054f1038 by task kworker/u17:1/182\n\n CPU: 0 UID: 0 PID: 182 Comm: kworker/u17:1 Tainted: G B 7.2.0-rc5-TWIDE-gb8babf08acc7 #1 PREEMPT(lazy)\n Tainted: [B]=BAD_PAGE\n Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Workqueue: isert_comp_wq isert_do_control_comp\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x53/0x70\n print_report+0xd0/0x630\n ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n ? _raw_spin_unlock_irqrestore+0x3e/0x70\n ? isert_put_cmd+0x53d/0x620\n kasan_report+0xce/0x100\n ? isert_put_cmd+0x53d/0x620\n isert_put_cmd+0x53d/0x620\n ? isert_completion_put+0x305/0x330\n ? isert_do_control_comp+0x2ef/0x310\n process_one_work+0x633/0x1030\n ? assign_work+0x11d/0x370\n worker_thread+0x45b/0xd10\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x2c6/0x3b0\n ? recalc_sigpending+0x15c/0x1e0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x36e/0x5a0\n ? __pfx_ret_from_fork+0x10/0x10\n ? __switch_to+0x572/0xdd0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 48:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n __kmalloc_cache_noprof+0x158/0x370\n isert_cma_handler+0x1e3/0x2ae0\n cma_cm_event_handler+0x3e/0x240\n cma_ib_req_handler+0x17d9/0x4490\n cm_process_work+0x41/0x330\n cm_work_handler+0x5727/0xc160\n process_one_work+0x633/0x1030\n worker_thread+0x45b/0xd10\n kthread+0x2c6/0x3b0\n ret_from_fork+0x36e/0x5a0\n ret_from_fork_asm+0x1a/0x30\n\n Freed by task 184:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x43/0x70\n kfree+0x121/0x380\n iscsit_close_connection+0x7cf/0x1e60\n iscsit_take_action_for_connection_exit+0x1b6/0x360\n iscsi_target_tx_thread+0x472/0x690\n kthread+0x2c6/0x3b0\n ret_from_fork+0x36e/0x5a0\n ret_from_fork_asm+0x1a/0x30(CVE-2026-98357)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Reject unregistering netdevs in ib_get_eth_speed\n\nib_device_get_netdev() intentionally returns a referenced net_device even\nwhen it is unregistering, so matching and cleanup callers can still find\nthe association. The reference keeps struct net_device allocated, but does\nnot guarantee that the device remains operational.\n\nib_get_eth_speed() uses the returned device operationally by invoking its\nethtool callback. Although that call is made under RTNL, the function does\nnot verify the registration state first. An asynchronous RDMA port query\ncan therefore call into a netdev after NETDEV_UNREGISTER and ndo_uninit\nhave completed.\n\nCheck for NETREG_REGISTERED while holding RTNL and return -ENODEV for a\ndevice which is being unregistered. Keeping RTNL across the check and the\nethtool operation prevents unregister from starting between them.\n\nKeep the speed fallback and warning under RTNL as well, so the warning can\nsafely read netdev-\u0026gt;name. Drop the netdev reference before releasing RTNL\nonce all accesses to the device are complete.(CVE-2026-98359)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB access\n\nmr_check_range() validates that [iova, iova+length) falls within the\nregistered MR range using wraparound-prone arithmetic:\n\n if (iova \u0026lt; mr-\u0026gt;ibmr.iova ||\n iova + length \u0026gt; mr-\u0026gt;ibmr.iova + mr-\u0026gt;ibmr.length)\n\nA remote peer can craft an RDMA-Write/Read RETH so that iova + length\nwraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing the\ncheck. rxe_mr_iova_to_index() then computes a huge index (int idx, only\nguarded by WARN_ON) and rxe_mr_copy_xarray() dereferences\nmr-\u0026gt;page_info[huge], causing an out-of-bounds read/write and a kernel\noops that is triggerable by an unauthenticated remote peer.\n\nRewrite the check in overflow-safe form; the first two clauses guarantee\nthat the subsequent subtractions do not underflow:\n\n if (iova \u0026lt; mr-\u0026gt;ibmr.iova ||\n length \u0026gt; mr-\u0026gt;ibmr.length ||\n iova - mr-\u0026gt;ibmr.iova \u0026gt; mr-\u0026gt;ibmr.length - length)\n\nWith the fix, mr_check_range() returns -EINVAL for the crafted iova and\nthe responder reports REMOTE_ACCESS_ERROR instead of triggering the OOB.(CVE-2026-98365)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: validate checksum_start before completing checksum\n\nIf a packet with bad checksum metadata gets into the ipv4 stack,\nskb_checksum_help can corrupt the network header and cause a bunch of\nmischief.\n\nThis was discovered and reported by Paulos, and has been reporoduced\nby others independently since.\n\nWe really shouldn\u0026apos;t allow such packets in, but as a defence\nin depth measure, let\u0026apos;s also check before we complete the checksum.\n\nA more complete validation at input is forthcoming, but needs more work.(CVE-2026-99999)",
"id": "OESA-2026-4591",
"modified": "2026-10-29T09:03:19Z",
"published": "2026-10-29T09:03:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4591"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40233"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71152"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43075"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53146"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53189"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53253"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53254"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53349"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63833"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64277"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64363"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64532"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64541"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68479"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74498"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74507"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74508"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74581"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74583"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74630"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80590"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80681"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80714"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81002"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89448"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89488"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89528"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89530"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89544"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89545"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89554"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89654"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89662"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89665"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89666"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89669"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89671"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89674"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89675"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89680"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89696"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89709"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89860"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90103"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90382"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93260"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93826"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97444"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97445"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97448"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97450"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97451"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97452"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97454"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97455"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97531"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97536"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97576"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97612"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97940"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98041"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98056"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98096"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98108"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98222"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98252"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98253"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98276"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98357"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98359"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98365"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99999"
}
],
"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-40233",
"CVE-2025-71152",
"CVE-2026-43075",
"CVE-2026-53146",
"CVE-2026-53189",
"CVE-2026-53253",
"CVE-2026-53254",
"CVE-2026-53349",
"CVE-2026-63833",
"CVE-2026-64277",
"CVE-2026-64363",
"CVE-2026-64532",
"CVE-2026-64541",
"CVE-2026-68479",
"CVE-2026-74498",
"CVE-2026-74507",
"CVE-2026-74508",
"CVE-2026-74581",
"CVE-2026-74583",
"CVE-2026-74630",
"CVE-2026-74739",
"CVE-2026-80590",
"CVE-2026-80681",
"CVE-2026-80714",
"CVE-2026-81001",
"CVE-2026-81002",
"CVE-2026-89448",
"CVE-2026-89488",
"CVE-2026-89528",
"CVE-2026-89530",
"CVE-2026-89544",
"CVE-2026-89545",
"CVE-2026-89554",
"CVE-2026-89654",
"CVE-2026-89662",
"CVE-2026-89665",
"CVE-2026-89666",
"CVE-2026-89669",
"CVE-2026-89671",
"CVE-2026-89674",
"CVE-2026-89675",
"CVE-2026-89680",
"CVE-2026-89685",
"CVE-2026-89696",
"CVE-2026-89709",
"CVE-2026-89860",
"CVE-2026-90103",
"CVE-2026-90382",
"CVE-2026-93260",
"CVE-2026-93817",
"CVE-2026-93826",
"CVE-2026-97444",
"CVE-2026-97445",
"CVE-2026-97448",
"CVE-2026-97450",
"CVE-2026-97451",
"CVE-2026-97452",
"CVE-2026-97454",
"CVE-2026-97455",
"CVE-2026-97531",
"CVE-2026-97536",
"CVE-2026-97576",
"CVE-2026-97612",
"CVE-2026-97935",
"CVE-2026-97940",
"CVE-2026-98041",
"CVE-2026-98056",
"CVE-2026-98096",
"CVE-2026-98108",
"CVE-2026-98222",
"CVE-2026-98252",
"CVE-2026-98253",
"CVE-2026-98276",
"CVE-2026-98357",
"CVE-2026-98359",
"CVE-2026-98365",
"CVE-2026-99999"
]
}
OPENSUSE-SU-2026:20145-1
Vulnerability from csaf_opensuse - Published: 2026-02-02 11:54 - Updated: 2026-10-12 17:33SUSE-SU-2026:0263-1
Vulnerability from csaf_suse - Published: 2026-01-22 21:15 - Updated: 2026-10-28 17:53SUSE-SU-2026:0278-1
Vulnerability from csaf_suse - Published: 2026-01-23 15:08 - Updated: 2026-10-28 17:53SUSE-SU-2026:0281-1
Vulnerability from csaf_suse - Published: 2026-01-23 16:03 - Updated: 2026-01-23 16:03Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
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.