Vulnerability-Lookup

CVE-2026-64546 (GCVE-0-2026-64546)

Vulnerability from cvelistv5 – Published: 2026-07-27 20:10 – Updated: 2026-08-17 04:57

Title

drm/edid: fix OOB read in drm_parse_tiled_block()

Summary

In the Linux kernel, the following vulnerability has been resolved: drm/edid: fix OOB read in drm_parse_tiled_block() drm_parse_tiled_block() casts the DisplayID block to a struct displayid_tiled_block and reads the full fixed layout up to tile->topology_id[7] without checking block->num_bytes. The DisplayID iterator only validates the declared payload length, so a crafted EDID can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at the end of a DisplayID extension. The read then runs past the end of the exact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read. Reject blocks shorter than the spec's 22-byte tiled payload before reading the fixed struct, as drm_parse_vesa_mso_data() already does. BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update Read of size 2 at addr ffff888010077700 by task exploit/147 dump_stack_lvl (lib/dump_stack.c:94 ...) print_report (mm/kasan/report.c:378 ...) kasan_report (mm/kasan/report.c:595) drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581) bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574) drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426) status_store (drivers/gpu/drm/drm_sysfs.c:219) ... vfs_write (fs/read_write.c:595 fs/read_write.c:688) ksys_write (fs/read_write.c:740)

Severity

7.1 (High)


                        
                          CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H

Assigner

Linux mitre root Scorecard

References

8 references

URL	Tags
https://git.kernel.org/stable/c/c4ab04ca1bbf87eef…
https://git.kernel.org/stable/c/9acd5c1ddc17ca4c5…
https://git.kernel.org/stable/c/157727131ce8a52d8…
https://git.kernel.org/stable/c/bfa05d89dc3ca3fb1…
https://git.kernel.org/stable/c/4f5484d25f85ad6c9…
https://git.kernel.org/stable/c/9cc0f8e63e8c34cf4…
https://git.kernel.org/stable/c/4137e1ecec9c8cb6c…
https://git.kernel.org/stable/c/faaa1e1155833e7d4…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 40d9b043a89e2301e1f97ade055a73ecc28e9afe , < c4ab04ca1bbf87eefa9fec5c80e1880450d2e7c0 (git) Affected: 40d9b043a89e2301e1f97ade055a73ecc28e9afe , < 9acd5c1ddc17ca4c5ffa0c373e3fdf480506e061 (git) Affected: 40d9b043a89e2301e1f97ade055a73ecc28e9afe , < 157727131ce8a52d8d9bc676c372ef82db6436c4 (git) Affected: 40d9b043a89e2301e1f97ade055a73ecc28e9afe , < bfa05d89dc3ca3fb1a9099ef5185549a5ec8490d (git) Affected: 40d9b043a89e2301e1f97ade055a73ecc28e9afe , < 4f5484d25f85ad6c989bad5f6a43450cecfcfd28 (git) Affected: 40d9b043a89e2301e1f97ade055a73ecc28e9afe , < 9cc0f8e63e8c34cf43def35cbd305ba711181a1f (git) Affected: 40d9b043a89e2301e1f97ade055a73ecc28e9afe , < 4137e1ecec9c8cb6c4fcee28ffabbbc7409eb7fb (git) Affected: 40d9b043a89e2301e1f97ade055a73ecc28e9afe , < faaa1e1155833e7d4ce7e3cfaf64c0d636b190db (git)	guessed
Linux	Linux	Affected: 3.19 Unaffected: 0 , < 3.19 (semver) Unaffected: 5.10.261 , ≤ 5.10.* (semver) Unaffected: 5.15.212 , ≤ 5.15.* (semver) Unaffected: 6.1.178 , ≤ 6.1.* (semver) Unaffected: 6.6.145 , ≤ 6.6.* (semver) Unaffected: 6.12.97 , ≤ 6.12.* (semver) Unaffected: 6.18.40 , ≤ 6.18.* (semver) Unaffected: 7.1.5 , ≤ 7.1.* (semver) Unaffected: 7.2 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/gpu/drm/drm_edid.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "c4ab04ca1bbf87eefa9fec5c80e1880450d2e7c0",
              "status": "affected",
              "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
              "versionType": "git"
            },
            {
              "lessThan": "9acd5c1ddc17ca4c5ffa0c373e3fdf480506e061",
              "status": "affected",
              "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
              "versionType": "git"
            },
            {
              "lessThan": "157727131ce8a52d8d9bc676c372ef82db6436c4",
              "status": "affected",
              "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
              "versionType": "git"
            },
            {
              "lessThan": "bfa05d89dc3ca3fb1a9099ef5185549a5ec8490d",
              "status": "affected",
              "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
              "versionType": "git"
            },
            {
              "lessThan": "4f5484d25f85ad6c989bad5f6a43450cecfcfd28",
              "status": "affected",
              "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
              "versionType": "git"
            },
            {
              "lessThan": "9cc0f8e63e8c34cf43def35cbd305ba711181a1f",
              "status": "affected",
              "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
              "versionType": "git"
            },
            {
              "lessThan": "4137e1ecec9c8cb6c4fcee28ffabbbc7409eb7fb",
              "status": "affected",
              "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
              "versionType": "git"
            },
            {
              "lessThan": "faaa1e1155833e7d4ce7e3cfaf64c0d636b190db",
              "status": "affected",
              "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/gpu/drm/drm_edid.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "3.19"
            },
            {
              "lessThan": "3.19",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.261",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.212",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.178",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.145",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.97",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.40",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.1.*",
              "status": "unaffected",
              "version": "7.1.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.261",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.212",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.178",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.145",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.97",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.40",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1.5",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2",
                  "versionStartIncluding": "3.19",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/edid: fix OOB read in drm_parse_tiled_block()\n\ndrm_parse_tiled_block() casts the DisplayID block to a\nstruct displayid_tiled_block and reads the full fixed layout up to\ntile-\u003etopology_id[7] without checking block-\u003enum_bytes. The DisplayID\niterator only validates the declared payload length, so a crafted EDID\ncan advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or\nDATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at\nthe end of a DisplayID extension. The read then runs past the end of the\nexact-sized kmemdup()\u0027d EDID allocation, a heap out-of-bounds read.\n\nReject blocks shorter than the spec\u0027s 22-byte tiled payload before\nreading the fixed struct, as drm_parse_vesa_mso_data() already does.\n\n  BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update\n  Read of size 2 at addr ffff888010077700 by task exploit/147\n   dump_stack_lvl (lib/dump_stack.c:94 ...)\n   print_report (mm/kasan/report.c:378 ...)\n   kasan_report (mm/kasan/report.c:595)\n   drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581)\n   bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574)\n   drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426)\n   status_store (drivers/gpu/drm/drm_sysfs.c:219)\n   ...\n   vfs_write (fs/read_write.c:595 fs/read_write.c:688)\n   ksys_write (fs/read_write.c:740)"
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The crafted EDID reaches the parser through a local device node \u2014 an unprivileged DRM client supplying a raw EDID buffer via the exynos vidi `DRM_AUTH` ioctl, or root via the connector\u0027s debugfs `edid_override` plus a sysfs re-probe. No network path exists, and local ioctl delivery is the lowest-friction vector (a physically attached malicious monitor/dock is an additional, equally automatic route).\nAC:L - The attacker fully controls the EDID bytes and only needs to place a tiled-display DisplayID block with a small `num_bytes` at the tail of the last extension block; `drm_edid_valid()` checks nothing but the header and checksums, which the attacker computes. No race and no memory-layout precondition is needed to trigger the read.\nPR:L - Handing an arbitrary EDID to `drm_edid_connector_update()` via `DRM_IOCTL_EXYNOS_VIDI_CONNECTION` requires only an authenticated DRM client (`DRM_AUTH`), i.e. an ordinary logged-in user with access to /dev/dri \u2014 no CAP_SYS_ADMIN and no root.\nUI:N - The attacker drives the connector probe itself through the ioctl, and on the hotplug path the EDID is read and parsed automatically by the kernel. No victim action is involved.\nS:U - The out-of-bounds read stays within the kernel\u0027s own heap and the impact is confined to the kernel security authority; no hypervisor, IOMMU, or sandbox boundary is crossed.\nC:H - Up to ~21 bytes of adjacent slab memory are read past the exact-size EDID allocation, and eight of those bytes are persisted into the connector\u0027s tile fields and handed back to userspace in the TILE property blob via `DRM_IOCTL_MODE_GETPROPBLOB`, giving a repeatable heap-content leak usable to defeat KASLR or recover neighbouring object data.\nI:N - The defect is purely a read; `drm_mode_create_tile_group()` copies the OOB source into a properly sized destination, so no out-of-bounds write or control-flow corruption occurs.\nA:H - The read runs past the end of the slab object and, for exact-fit allocations at a slab boundary, can touch unmapped memory; on KASAN or panic_on_warn kernels it is an immediate fatal report, and the resulting garbage tile geometry is propagated to the modesetting path."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-17T04:57:23.260Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/c4ab04ca1bbf87eefa9fec5c80e1880450d2e7c0"
        },
        {
          "url": "https://git.kernel.org/stable/c/9acd5c1ddc17ca4c5ffa0c373e3fdf480506e061"
        },
        {
          "url": "https://git.kernel.org/stable/c/157727131ce8a52d8d9bc676c372ef82db6436c4"
        },
        {
          "url": "https://git.kernel.org/stable/c/bfa05d89dc3ca3fb1a9099ef5185549a5ec8490d"
        },
        {
          "url": "https://git.kernel.org/stable/c/4f5484d25f85ad6c989bad5f6a43450cecfcfd28"
        },
        {
          "url": "https://git.kernel.org/stable/c/9cc0f8e63e8c34cf43def35cbd305ba711181a1f"
        },
        {
          "url": "https://git.kernel.org/stable/c/4137e1ecec9c8cb6c4fcee28ffabbbc7409eb7fb"
        },
        {
          "url": "https://git.kernel.org/stable/c/faaa1e1155833e7d4ce7e3cfaf64c0d636b190db"
        }
      ],
      "title": "drm/edid: fix OOB read in drm_parse_tiled_block()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-64546",
    "datePublished": "2026-07-27T20:10:37.217Z",
    "dateReserved": "2026-07-19T15:36:31.795Z",
    "dateUpdated": "2026-08-17T04:57:23.260Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-64546",
      "date": "2026-10-05",
      "epss": "0.00167",
      "percentile": "0.05349"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/gpu/drm/drm_edid.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "c4ab04ca1bbf87eefa9fec5c80e1880450d2e7c0",
                    "status": "affected",
                    "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "9acd5c1ddc17ca4c5ffa0c373e3fdf480506e061",
                    "status": "affected",
                    "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "157727131ce8a52d8d9bc676c372ef82db6436c4",
                    "status": "affected",
                    "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "bfa05d89dc3ca3fb1a9099ef5185549a5ec8490d",
                    "status": "affected",
                    "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "4f5484d25f85ad6c989bad5f6a43450cecfcfd28",
                    "status": "affected",
                    "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "9cc0f8e63e8c34cf43def35cbd305ba711181a1f",
                    "status": "affected",
                    "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "4137e1ecec9c8cb6c4fcee28ffabbbc7409eb7fb",
                    "status": "affected",
                    "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "faaa1e1155833e7d4ce7e3cfaf64c0d636b190db",
                    "status": "affected",
                    "version": "40d9b043a89e2301e1f97ade055a73ecc28e9afe",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/gpu/drm/drm_edid.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "3.19"
                  },
                  {
                    "lessThan": "3.19",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.261",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.212",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.178",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.145",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.12.*",
                    "status": "unaffected",
                    "version": "6.12.97",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.18.*",
                    "status": "unaffected",
                    "version": "6.18.40",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "7.1.*",
                    "status": "unaffected",
                    "version": "7.1.5",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.2",
                    "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\ndrm/edid: fix OOB read in drm_parse_tiled_block()\n\ndrm_parse_tiled_block() casts the DisplayID block to a\nstruct displayid_tiled_block and reads the full fixed layout up to\ntile-\u003etopology_id[7] without checking block-\u003enum_bytes. The DisplayID\niterator only validates the declared payload length, so a crafted EDID\ncan advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or\nDATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at\nthe end of a DisplayID extension. The read then runs past the end of the\nexact-sized kmemdup()\u0027d EDID allocation, a heap out-of-bounds read.\n\nReject blocks shorter than the spec\u0027s 22-byte tiled payload before\nreading the fixed struct, as drm_parse_vesa_mso_data() already does.\n\n  BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update\n  Read of size 2 at addr ffff888010077700 by task exploit/147\n   dump_stack_lvl (lib/dump_stack.c:94 ...)\n   print_report (mm/kasan/report.c:378 ...)\n   kasan_report (mm/kasan/report.c:595)\n   drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581)\n   bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574)\n   drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426)\n   status_store (drivers/gpu/drm/drm_sysfs.c:219)\n   ...\n   vfs_write (fs/read_write.c:595 fs/read_write.c:688)\n   ksys_write (fs/read_write.c:740)"
          }
        ],
        "id": "CVE-2026-64546",
        "lastModified": "2026-08-17T05:17:59.813",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.1,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.2,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-07-27T21:17:07.270",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/157727131ce8a52d8d9bc676c372ef82db6436c4"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/4137e1ecec9c8cb6c4fcee28ffabbbc7409eb7fb"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/4f5484d25f85ad6c989bad5f6a43450cecfcfd28"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/9acd5c1ddc17ca4c5ffa0c373e3fdf480506e061"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/9cc0f8e63e8c34cf43def35cbd305ba711181a1f"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/bfa05d89dc3ca3fb1a9099ef5185549a5ec8490d"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/c4ab04ca1bbf87eefa9fec5c80e1880450d2e7c0"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/faaa1e1155833e7d4ce7e3cfaf64c0d636b190db"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Received"
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-07-30T08:28:34+00:00",
      "cve": "CVE-2026-64546",
      "id": "CVE-2026-64546",
      "initial_release_date": "2026-07-27T00:00:00+00:00",
      "product_status:known_affected": "246",
      "product_status:known_not_affected": "28",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: drm/edid: fix OOB read in drm_parse_tiled_block()",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-64546.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-10-03T00:41:50Z",
      "cve": "CVE-2026-64546",
      "id": "CVE-2026-64546",
      "initial_release_date": "2026-07-28T17:07:59Z",
      "product_status:known_affected": "673",
      "product_status:known_not_affected": "62",
      "product_status:recommended": "256",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2026-64546",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-64546.json",
      "version": "14"
    }
  }
}

OESA-2026-3532 (CVE-2022-49289)

Vulnerability from osv_openeuler – Published: 2026-08-30 04:15 – Updated: 2026-08-30 04:15 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

uaccess: fix integer overflow on access_ok()

Three architectures check the end of a user access against the address limit without taking a possible overflow into account. Passing a negative length or another overflow in here returns success when it should not.

Use the most common correct implementation here, which optimizes for a constant 'size' argument, and turns the common case into a single comparison.(CVE-2022-49289)

In the Linux kernel, the following vulnerability has been resolved:

parisc: Fix double SIGFPE crash

Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately.

When the T bit is set, an assist exception trap occurs when when the co-processor encounters any floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace.

The issue can be reproduced with this test program:

root@parisc:~# cat fpe.c

static void fpe_func(int sig, siginfo_t i, void v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); }

int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); }

root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception

root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 / 20 vars /) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception(CVE-2025-37991)

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()

kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries.

Return -ENOMEM on allocation failure to avoid the NULL dereference.(CVE-2025-68190)

In the Linux kernel, the following vulnerability has been resolved:

arm64/fpsimd: signal: Fix restoration of SVE context

When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL.

(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL.

This can only occur in unusual (but legitimate) cases where the SVE
signal context has either been modified by userspace or was saved in
the context of another task (e.g. as with CRIU), as otherwise the
presence of an SVE signal context with SVE_SIG_FLAG_SM implies that
TIF_SME is already set.

While in this state, task_fpsimd_load() will NOT configure SMCR_ELx
(leaving some arbitrary value configured in hardware) before
restoring SVCR and attempting to restore the streaming mode SVE
registers from memory via sve_load_state(). As the value of
SMCR_ELx.LEN may be larger than the task&apos;s streaming SVE vector
length, this may read memory outside of the task&apos;s allocated
sve_state, reading unrelated data and/or triggering a fault.

While this can result in secrets being loaded into streaming SVE
registers, these values are never exposed. As TIF_SME is clear,
fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0
accesses to streaming mode SVE registers, so these cannot be
accessed directly at EL0. As fpsimd_save_user_state() verifies the
live vector length before saving (S)SVE state to memory, no secret
values can be saved back to memory (and hence cannot be observed via
ptrace, signals, etc).

When the live vector length doesn&apos;t match the expected vector length
for the task, fpsimd_save_user_state() will send a fatal SIGKILL
signal to the task. Hence the task may be killed after executing
userspace for some period of time.

(2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV.

This can only occur in unusual (but legitimate) cases where ptrace
has been used to set SVCR.SM after entry to the sigreturn syscall,
as syscall entry clears SVCR.SM.

In these cases, the the provided SVE register data will be loaded
into the task&apos;s sve_state using the non-streaming SVE vector length
and the FPSIMD registers will be merged into this using the
streaming SVE vector length.

Fix (1) by setting TIF_SME when setting SVCR.SM. This also requires ensuring that the task's sme_state has been allocated, but as this could contain live ZA state, it should not be zeroed. Fix (2) by clearing SVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.

For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME, and fp_type earlier, immediately after the allocation of sve_state/sme_state, before the restore of the actual register state. This makes it easier to ensure that these are always modified consistently, even if a fault is taken while reading the register data from the signal context. I do not expect any software to depend on the exact state restored when a fault is taken while reading the context.(CVE-2026-23102)

In the Linux kernel, the following vulnerability has been resolved:

net: ncsi: fix skb leak in error paths

Early return paths in NCSI RX and AEN handlers fail to release the received skb, resulting in a memory leak.

Specifically, ncsi_aen_handler() returns on invalid AEN packets without consuming the skb. Similarly, ncsi_rcv_rsp() exits early when failing to resolve the NCSI device, response handler, or request, leaving the skb unfreed.(CVE-2026-43373)

In the Linux kernel, the following vulnerability has been resolved: selinux: fix overlayfs mmap() and mprotect() access checks The existing SELinux security model for overlayfs is to allow access if the current task is able to access the top level file (the "user" file) and the mounter's credentials are sufficient to access the lower level file (the "backing" file). Unfortunately, the current code does not properly enforce these access controls for both mmap() and mprotect() operations on overlayfs filesystems. This patch makes use of the newly created security_mmap_backing_file() LSM hook to provide the missing backing file enforcement for mmap() operations, and leverages the backing file API and new LSM blob to provide the necessary information to properly enforce the mprotect() access controls. The Linux kernel CVE team has assigned CVE-2026-46054 to this issue.(CVE-2026-46054)

In the Linux kernel, the following vulnerability has been resolved:

fbcon: Avoid OOB font access if console rotation fails

Clear the font buffer if the reallocation during console rotation fails in fbcon_rotate_font(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example.

Currently, fbcon_rotate_font() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer.

v2: - fix typos in commit message(CVE-2026-46191)

In the Linux kernel, the following vulnerability has been resolved:

vsock: fix buffer size clamping order

In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint.

This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size.

Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size.(CVE-2026-46234)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths

Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart.

The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the hu struct. When the scheduled work executes later, it blindly dereferences the freed hu struct.

Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently.

Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.(CVE-2026-46275)

In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: terminate the cached volume label after UTF-8 conversion

ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s() and stores the result in sbi->volume.label. The converted label is later exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only returns the number of bytes written and does not add a trailing NUL.

If the converted label fills the entire fixed buffer, ntfs3_label_show() can read past the end of sbi->volume.label while looking for a terminator.

Terminate the cached label explicitly after a successful conversion and clamp the exact-full case to the last byte of the buffer.(CVE-2026-53023)

In the Linux kernel, the following vulnerability has been resolved:

ocfs2/dlm: validate qr_numregions in dlm_match_regions()

Patch series "ocfs2/dlm: fix two bugs in dlm_match_regions()".

In dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGION network message is used to drive loops over the qr_regions buffer without sufficient validation. This series fixes two issues:

Patch 1 adds a bounds check to reject messages where qr_numregions exceeds O2NM_MAX_REGIONS. The o2net layer only validates message byte length; it does not constrain field values, so a crafted message can set qr_numregions up to 255 and trigger out-of-bounds reads past the 1024-byte qr_regions buffer.
Patch 2 fixes an off-by-one in the local-vs-remote comparison loop, which uses '<=' instead of '<', reading one entry past the valid range even when qr_numregions is within bounds.

This patch (of 2):

The qr_numregions field from a DLM_QUERY_REGION network message is used directly as loop bounds in dlm_match_regions() without checking against O2NM_MAX_REGIONS. Since qr_regions is sized for at most O2NM_MAX_REGIONS (32) entries, a crafted message with qr_numregions > 32 causes out-of-bounds reads past the qr_regions buffer.

Add a bounds check for qr_numregions before entering the loops.(CVE-2026-53043)

In the Linux kernel, the following vulnerability has been resolved:

wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet

The irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and scheduled when RTL_IMR_BCNINT interrupt is triggered by hardware. But it is never killed in rtl_pci_deinit(). When the rtlwifi card probe fails or is being detached, the ieee80211_hw is deallocated. However, irq_prepare_bcn_tasklet may still be running or pending, leading to use-after-free when the freed ieee80211_hw is accessed in _rtl_pci_prepare_bcn_tasklet().

Similar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to ensure that irq_prepare_bcn_tasklet is properly terminated before the ieee80211_hw is released.

The issue was identified through static analysis.(CVE-2026-53112)

In the Linux kernel, the following vulnerability has been resolved:

PCI: use generic driver_override infrastructure

When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from __driver_attach() without the device lock held is intentional. 1

In the Linux kernel, the following vulnerability has been resolved:

net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink

A tunnel changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Add rtnl_dev_link_net_capable() next to rtnl_get_net_ns_capable() in net/core/rtnetlink.c. It requires CAP_NET_ADMIN in the link netns and is skipped when the link netns is dev_net(dev), where the rtnl path already checked it. The other patches in this series use the same helper.

Gate ipgre_changelink() and erspan_changelink() with it, at the top of the op before any attribute is parsed, because the parsers update live tunnel fields first. ipgre_netlink_parms() sets t->collect_md before ip_tunnel_changelink() runs.

Commit 8b484efd5cb4 ("ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().") added the same check on the ioctl path. This adds it on RTM_NEWLINK.(CVE-2026-63829)

In the Linux kernel, the following vulnerability has been resolved:

ipv6: validate extension header length before copying to cmsg

ip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR} cmsgs (and their IPV6_2292* legacy counterparts) by trusting the on-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length. The length was validated only at parse time (ipv6_parse_hopopts(), etc.). An nftables payload-write expression can rewrite hdrlen after parsing and before the skb reaches recvmsg; the write itself is in-bounds but put_cmsg() then reads up to ((hdrlen+1) << 3) = 2040 bytes from an 8-byte header. nftables is reachable from an unprivileged user namespace, so this is an unprivileged slab-out-of-bounds read:

BUG: KASAN: slab-out-of-bounds in put_cmsg+0x3ac/0x540 put_cmsg+0x3ac/0x540 udpv6_recvmsg+0xca0/0x1250 sock_recvmsg+0xdf/0x190 ____sys_recvmsg+0x1b1/0x620

Add ipv6_get_exthdr_len() which validates that at least two bytes are accessible before reading the hdrlen field, then checks the computed length against skb_tail_pointer(skb), returning 0 on failure. Extension headers are kept in the linear skb area by pskb_may_pull() during input, so skb_tail_pointer() is the correct bound.

Use ipv6_get_exthdr_len() at all non-AH call sites: the five standalone cmsg blocks (HbH, 2292HbH, 2292DSTOPTS x2, 2292RTHDR) and the three standard cases in the extension-header walk loop (DSTOPTS, ROUTING, default). AH retains an inline bounds check because its length formula differs ((ptr[1]+2)<<2).

The walk loop also gets a pre-read bounds check at the top to validate ptr before any case accesses ptr[0] or ptr[1].

When the walk loop detects a corrupted header, return from the function instead of continuing to process later socket options.(CVE-2026-63920)

In the Linux kernel, the following vulnerability has been resolved:

ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().

After patch 1/2 in this series, vti6_update() unlinks and relinks the tunnel through t->net. vti6_siocdevprivate() still uses dev_net(dev) for the collision lookup. For a tunnel moved through IFLA_NET_NS_FD, dev_net(dev) is the new netns, not t->net.

SIOCCHGTUNNEL on a migrated tunnel then runs:

net = dev_net(dev) / migrated netns / t = vti6_locate(net, &p1, false) / misses target in t->net / ... t = netdev_priv(dev) vti6_update(t, &p1, false) / mutates t->net's hash /

A caller in the migrated netns picks params that match a tunnel in the creation netns. The lookup in dev_net(dev) finds nothing. vti6_update() prepends the migrated tunnel at the head of the creation netns hash bucket for those params. Later lookups in the creation netns resolve to the migrated device. xfrm receive delivers the matched packets through a device the caller controls.

Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts.

Switch the SIOCCHGTUNNEL path on a non fallback device to use t->net for the lookup. The lookup now matches the netns vti6_update() operates on.

Also add ns_capable(self->net->user_ns, CAP_NET_ADMIN) before the lookup. The check at the top of the case is against dev_net(dev)->user_ns, which after migration is the attacker's netns. A caller there can pick params absent from self->net, the lookup returns NULL, t becomes self, and vti6_update() inserts the device into the creation netns hash. The new check requires CAP_NET_ADMIN in the creation netns user_ns too.

SIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep dev_net(dev), which equals init_net there.(CVE-2026-63921)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: synproxy: refresh tcphdr after skb_ensure_writable

synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer.

Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale:

caller (ipv[46]_synproxy_hook)
  th = skb_header_pointer(skb, ..., &amp;_tcph)
  synproxy_tstamp_adjust(skb, protoff, th, ...)
    skb_ensure_writable(skb, optend)
      pskb_expand_head()        /* kfree(old skb-&gt;head) */
    ...
    inet_proto_csum_replace4(&amp;th-&gt;check, ...)
                                /* writes into freed head, or
                                   into the caller&apos;s stack copy
                                   leaving the on-wire checksum
                                   stale */

The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload.

Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.(CVE-2026-64007)

In the Linux kernel, the following vulnerability has been resolved:

ipv4: raw: reject IP_HDRINCL packets with ihl < 5

raw_send_hdrinc() validates that the caller-supplied IPv4 header fits within the message length:

iphlen = iph-&gt;ihl * 4;
err = -EINVAL;
if (iphlen &gt; length)
    goto error_free;

if (iphlen &gt;= sizeof(*iph)) {
    /* fix up saddr, tot_len, id, csum, transport_header */
}

It does not, however, reject ihl < 5. For such a packet the "if (iphlen >= sizeof(*iph))" branch is skipped, leaving the crafted iphdr untouched, but the packet is still handed to __ip_local_out() and onward. Downstream consumers that read iph->ihl assume a sane value: net/ipv4/ah4.c:ah_output() in particular subtracts sizeof(struct iphdr) from top_iph->ihl * 4 and passes the (signed-int-negative, then cast to size_t) result to memcpy(), producing an OOB access of length close to SIZE_MAX and a host kernel panic.

An IPv4 header with ihl < 5 is malformed by definition (RFC 791: "Internet Header Length is the length of the internet header in 32 bit words ... Note that the minimum value for a correct header is 5."). The kernel should not be willing to inject such a packet into its own output path.

Reject "iphlen < sizeof(*iph)" alongside the existing "iphlen > length" check. This matches the principle that locally constructed packets that re-enter the IP stack must pass the same basic sanity tests that a foreign packet would be subjected to.

Once this lands, the "if (iphlen >= sizeof(*iph))" wrapper around the fixup branch becomes redundant; left in place to keep the patch minimal and backport-friendly. A follow-up can unwrap it.

Note that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket message is big enough to hold an IP header") ensures the message buffer is large enough to hold an iphdr, but does not constrain the self-reported iph->ihl.

Reachability: the malformed packet source is any caller with CAP_NET_RAW, including an unprivileged process in a user+net namespace on a kernel with CONFIG_USER_NS=y. The reproduced AH crash also requires a matching xfrm AH policy on the outgoing route; a container granted CAP_NET_ADMIN can install that state and policy in its netns. Loopback bypasses xfrm_output, so the trigger uses a real netdev.

Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with memcpy_orig at the crash site. Same shape reproduces inside a rootless Docker container with --cap-add NET_ADMIN on a stock distro kernel.(CVE-2026-64114)

In the Linux kernel, the following vulnerability has been resolved:

ALSA: asihpi: Fix potential OOB array access at reading cache

find_control() to retrieve a cached info accesses the array with the given index blindly, which may lead to an OOB array access. Add a sanity check for avoiding it.(CVE-2026-64133)

In the Linux kernel, the following vulnerability has been resolved:

fuse: re-lock request before returning from fuse_ref_folio()

fuse_ref_folio() unlocks the request but does not re-lock it before returning. fuse_chan_abort() can end the request and the async end callback (eg fuse_writepage_free()) can free the args while the subsequent copy chain logic after fuse_ref_folio() accesses them, leading to use-after-free issues.

Fix this by locking the request in fuse_ref_folio() before returning.(CVE-2026-64266)

In the Linux kernel, the following vulnerability has been resolved:

net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes

Reject invalid net.ipv4.tcp_reordering values before they reach TCP socket state. The sysctl is stored as an int but copied into the u32 tp->reordering field for new sockets, so negative writes wrap to large values.

With tcp_mtu_probing=2, the wrapped value can overflow the tcp_mtu_probe() size calculation and drive the MTU probing path into an out-of-bounds read. Route tcp_reordering writes through proc_dointvec_minmax() and require it to be at least 1. Also require tcp_max_reordering to be at least 1 so the configured maximum cannot become negative either.

When registering the table for a non-init network namespace, relocate extra2 pointers that refer into init_net.ipv4 so the tcp_reordering upper bound follows that namespace's tcp_max_reordering.

Harden tcp_mtu_probe() itself by computing size_needed as u64. This keeps the send queue and window checks from being bypassed through signed integer overflow.(CVE-2026-64422)

In the Linux kernel, the following vulnerability has been resolved:

net: af_key: initialize alg_key_len for IPComp states

pfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by allocating x->calg and copying only the algorithm name:

x-&gt;calg = kmalloc_obj(*x-&gt;calg);
if (!x-&gt;calg) {
    err = -ENOMEM;
    goto out;
}
strcpy(x-&gt;calg-&gt;alg_name, a-&gt;name);
x-&gt;props.calgo = sa-&gt;sadb_sa_encrypt;

Unlike the authentication (x->aalg) and encryption (x->ealg) branches of the same function, the compression branch never initializes calg->alg_key_len. IPComp carries no key and the allocation only reserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field is left containing uninitialized slab data.

calg->alg_key_len is later used as a length by xfrm_algo_clone() when an IPComp state is cloned during XFRM_MSG_MIGRATE:

xfrm_state_migrate()
  xfrm_state_clone_and_setup()
    x-&gt;calg = xfrm_algo_clone(orig-&gt;calg);
      kmemdup(orig, xfrm_alg_len(orig));

where xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8. With a non-zero garbage alg_key_len, kmemdup() reads past the end of the 68-byte calg object. Adding an IPComp SA via PF_KEY and then migrating it triggers (net-next, KASAN, init_on_alloc=0):

BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60 Read of size 4164 at addr ff11000025a74980 by task diag2/9287 CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1 Call Trace: <TASK> dump_stack_lvl+0x10e/0x1f0 print_report+0xf7/0x600 kasan_report+0xe4/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x44/0x60 xfrm_state_migrate+0x70a/0x1da0 xfrm_migrate+0x753/0x18a0 xfrm_do_migrate+0xb47/0xf10 xfrm_user_rcv_msg+0x411/0xb50 netlink_rcv_skb+0x158/0x420 xfrm_netlink_rcv+0x71/0x90 netlink_unicast+0x584/0x850 netlink_sendmsg+0x8b0/0xdc0 _syssendmsg+0x9f7/0xb90 _sys_sendmsg+0x134/0x1d0 __sys_sendmsg+0x16d/0x220 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>

Allocated by task 9287: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 pfkey_add+0x2652/0x2ea0 pfkey_process+0x6d0/0x830 pfkey_sendmsg+0x42c/0x850 __sys_sendto+0x461/0x4b0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ff11000025a74980 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes inside of allocated 68-byte region [ff11000025a74980, ff11000025a749c4)

Depending on the uninitialized value the same field can instead request an oversized kmemdup() allocation and make the migration clone fail.

The XFRM netlink path is not affected: verify_one_alg() rejects an XFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via XFRM_MSG_NEWSA is always self-consistent.

Initialize calg->alg_key_len to 0, matching the aalg/ealg branches.(CVE-2026-64436)

In the Linux kernel, the following vulnerability has been resolved:

drm/edid: fix OOB read in drm_parse_tiled_block()

drm_parse_tiled_block() casts the DisplayID block to a struct displayid_tiled_block and reads the full fixed layout up to tile->topology_id[7] without checking block->num_bytes. The DisplayID iterator only validates the declared payload length, so a crafted EDID can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at the end of a DisplayID extension. The read then runs past the end of the exact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read.

Reject blocks shorter than the spec's 22-byte tiled payload before reading the fixed struct, as drm_parse_vesa_mso_data() already does.

BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update Read of size 2 at addr ffff888010077700 by task exploit/147 dump_stack_lvl (lib/dump_stack.c:94 ...) print_report (mm/kasan/report.c:378 ...) kasan_report (mm/kasan/report.c:595) drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581) bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574) drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426) status_store (drivers/gpu/drm/drm_sysfs.c:219) ... vfs_write (fs/read_write.c:595 fs/read_write.c:688) ksys_write (fs/read_write.c:740)(CVE-2026-64546)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: qca: fix NVM tag length underflow in TLV parser

In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is "while (idx < length - sizeof(struct tlv_type_nvm))". "length" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so "length" is converted to size_t and any firmware-supplied "length" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it).

Rewrite the bound as "idx + sizeof(struct tlv_type_nvm) <= length"; both operands are non-negative, so it no longer underflows and a "length" too small for one record correctly skips the loop.

BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)(CVE-2026-64573)

In the Linux kernel, the following vulnerability has been resolved:

ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()

ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case:

snaptrace     = h + 1;
snaptrace_len = le32_to_cpu(h-&gt;snap_trace_len);
p             = snaptrace + snaptrace_len;
...
case CEPH_CAP_OP_IMPORT:
    if (snaptrace_len) {
        ...
        if (ceph_update_snap_trace(mdsc, snaptrace,
                                   snaptrace + snaptrace_len,
                                   false, &amp;realm)) { ... }

ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays.

The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced.

Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.(CVE-2026-68160)

In the Linux kernel, the following vulnerability has been resolved:

tpm: Make the TPM character devices non-seekable

The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE enabled.

After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as off to tpm_common_read(). The transfer length is bounded by response_length, but the offset is used unchecked when forming data_buffer + off. A sufficiently large offset therefore causes an out-of-bounds heap read through copy_to_user() and, if the copy succeeds, an out-of-bounds zero-write through the following memset().

Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of data_buffer, while pwrite() does not update file->f_pos and can leave the sequential read cursor stale.

Call nonseekable_open() from both open handlers. This removes FMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential f_pos cursor, leaving the response state machine unchanged.

Tested on Linux 6.12 with KASAN and a swtpm TPM2 device:

sequential partial reads returned the complete response
pread() and preadv() with offset 0x1400 returned -ESPIPE
pwrite() and pwritev() with offset zero returned -ESPIPE
the pending response remained intact after the rejected operations
a subsequent normal command/response cycle completed normally
no KASAN report was produced.(CVE-2026-72135)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: xt_u32: reject invalid shift counts

u32_match_it() executes rule-supplied shift operands on a 32-bit value. A malformed u32 rule can provide a shift count of 32 or more, triggering an undefined shift out-of-bounds during packet evaluation.

Validate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in u32_mt_checkentry() and reject malformed rules before they reach the packet path.(CVE-2026-72350)

Severity

9.8 (Critical)


                    
                      CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49289	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-37991	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68190	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23102	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43373	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46054	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46191	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46234	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46275	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53023	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53043	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53112	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53120	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63829	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63920	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63921	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64007	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64114	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64133	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64266	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64422	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64436	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64546	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64573	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-68160	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72135	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72350	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-330.0.0.231.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-330.0.0.231.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-330.0.0.231.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\nuaccess: fix integer overflow on access_ok()\n\nThree architectures check the end of a user access against the\naddress limit without taking a possible overflow into account.\nPassing a negative length or another overflow in here returns\nsuccess when it should not.\n\nUse the most common correct implementation here, which optimizes\nfor a constant \u0026apos;size\u0026apos; argument, and turns the common case into a\nsingle comparison.(CVE-2022-49289)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix double SIGFPE crash\n\nCamm noticed that on parisc a SIGFPE exception will crash an application with\na second SIGFPE in the signal handler.  Dave analyzed it, and it happens\nbecause glibc uses a double-word floating-point store to atomically update\nfunction descriptors. As a result of lazy binding, we hit a floating-point\nstore in fpe_func almost immediately.\n\nWhen the T bit is set, an assist exception trap occurs when when the\nco-processor encounters *any* floating-point instruction except for a double\nstore of register %fr0.  The latter cancels all pending traps.  Let\u0026apos;s fix this\nby clearing the Trap (T) bit in the FP status register before returning to the\nsignal handler in userspace.\n\nThe issue can be reproduced with this test program:\n\nroot@parisc:~# cat fpe.c\n\nstatic void fpe_func(int sig, siginfo_t *i, void *v) {\n        sigset_t set;\n        sigemptyset(\u0026amp;set);\n        sigaddset(\u0026amp;set, SIGFPE);\n        sigprocmask(SIG_UNBLOCK, \u0026amp;set, NULL);\n        printf(\u0026quot;GOT signal %d with si_code %ld\\n\u0026quot;, sig, i-\u0026gt;si_code);\n}\n\nint main() {\n        struct sigaction action = {\n                .sa_sigaction = fpe_func,\n                .sa_flags = SA_RESTART|SA_SIGINFO };\n        sigaction(SIGFPE, \u0026amp;action, 0);\n        feenableexcept(FE_OVERFLOW);\n        return printf(\u0026quot;%lf\\n\u0026quot;,1.7976931348623158E308*1.7976931348623158E308);\n}\n\nroot@parisc:~# gcc fpe.c -lm\nroot@parisc:~# ./a.out\n Floating point exception\n\nroot@parisc:~# strace -f ./a.out\n execve(\u0026quot;./a.out\u0026quot;, [\u0026quot;./a.out\u0026quot;], 0xf9ac7034 /* 20 vars */) = 0\n getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0\n ...\n rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---\n +++ killed by SIGFPE +++\n Floating point exception(CVE-2025-37991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()\n\nkcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws\nremains NULL while ectx.ws_size is set, leading to a potential NULL\npointer dereference in atom_get_src_int() when accessing WS entries.\n\nReturn -ENOMEM on allocation failure to avoid the NULL dereference.(CVE-2025-68190)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64/fpsimd: signal: Fix restoration of SVE context\n\nWhen SME is supported, Restoring SVE signal context can go wrong in a\nfew ways, including placing the task into an invalid state where the\nkernel may read from out-of-bounds memory (and may potentially take a\nfatal fault) and/or may kill the task with a SIGKILL.\n\n(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into\n    an invalid state where SVCR.SM is set (and sve_state is non-NULL)\n    but TIF_SME is clear, consequently resuting in out-of-bounds memory\n    reads and/or killing the task with SIGKILL.\n\n    This can only occur in unusual (but legitimate) cases where the SVE\n    signal context has either been modified by userspace or was saved in\n    the context of another task (e.g. as with CRIU), as otherwise the\n    presence of an SVE signal context with SVE_SIG_FLAG_SM implies that\n    TIF_SME is already set.\n\n    While in this state, task_fpsimd_load() will NOT configure SMCR_ELx\n    (leaving some arbitrary value configured in hardware) before\n    restoring SVCR and attempting to restore the streaming mode SVE\n    registers from memory via sve_load_state(). As the value of\n    SMCR_ELx.LEN may be larger than the task\u0026apos;s streaming SVE vector\n    length, this may read memory outside of the task\u0026apos;s allocated\n    sve_state, reading unrelated data and/or triggering a fault.\n\n    While this can result in secrets being loaded into streaming SVE\n    registers, these values are never exposed. As TIF_SME is clear,\n    fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0\n    accesses to streaming mode SVE registers, so these cannot be\n    accessed directly at EL0. As fpsimd_save_user_state() verifies the\n    live vector length before saving (S)SVE state to memory, no secret\n    values can be saved back to memory (and hence cannot be observed via\n    ptrace, signals, etc).\n\n    When the live vector length doesn\u0026apos;t match the expected vector length\n    for the task, fpsimd_save_user_state() will send a fatal SIGKILL\n    signal to the task. Hence the task may be killed after executing\n    userspace for some period of time.\n\n(2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the\n    task\u0026apos;s SVCR.SM. If SVCR.SM was set prior to restoring the context,\n    then the task will be left in streaming mode unexpectedly, and some\n    register state will be combined inconsistently, though the task will\n    be left in legitimate state from the kernel\u0026apos;s PoV.\n\n    This can only occur in unusual (but legitimate) cases where ptrace\n    has been used to set SVCR.SM after entry to the sigreturn syscall,\n    as syscall entry clears SVCR.SM.\n\n    In these cases, the the provided SVE register data will be loaded\n    into the task\u0026apos;s sve_state using the non-streaming SVE vector length\n    and the FPSIMD registers will be merged into this using the\n    streaming SVE vector length.\n\nFix (1) by setting TIF_SME when setting SVCR.SM. This also requires\nensuring that the task\u0026apos;s sme_state has been allocated, but as this could\ncontain live ZA state, it should not be zeroed. Fix (2) by clearing\nSVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.\n\nFor consistency, I\u0026apos;ve pulled the manipulation of SVCR, TIF_SVE, TIF_SME,\nand fp_type earlier, immediately after the allocation of\nsve_state/sme_state, before the restore of the actual register state.\nThis makes it easier to ensure that these are always modified\nconsistently, even if a fault is taken while reading the register data\nfrom the signal context. I do not expect any software to depend on the\nexact state restored when a fault is taken while reading the context.(CVE-2026-23102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ncsi: fix skb leak in error paths\n\nEarly return paths in NCSI RX and AEN handlers fail to release\nthe received skb, resulting in a memory leak.\n\nSpecifically, ncsi_aen_handler() returns on invalid AEN packets\nwithout consuming the skb. Similarly, ncsi_rcv_rsp() exits early\nwhen failing to resolve the NCSI device, response handler, or\nrequest, leaving the skb unfreed.(CVE-2026-43373)\n\nIn the Linux kernel, the following vulnerability has been resolved:  selinux: fix overlayfs mmap() and mprotect() access checks  The existing SELinux security model for overlayfs is to allow access if the current task is able to access the top level file (the \u0026quot;user\u0026quot; file) and the mounter\u0026apos;s credentials are sufficient to access the lower level file (the \u0026quot;backing\u0026quot; file).  Unfortunately, the current code does not properly enforce these access controls for both mmap() and mprotect() operations on overlayfs filesystems.  This patch makes use of the newly created security_mmap_backing_file() LSM hook to provide the missing backing file enforcement for mmap() operations, and leverages the backing file API and new LSM blob to provide the necessary information to properly enforce the mprotect() access controls.  The Linux kernel CVE team has assigned CVE-2026-46054 to this issue.(CVE-2026-46054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: Avoid OOB font access if console rotation fails\n\nClear the font buffer if the reallocation during console rotation fails\nin fbcon_rotate_font(). The putcs implementations for the rotated buffer\nwill return early in this case. See [1] for an example.\n\nCurrently, fbcon_rotate_font() keeps the old buffer, which is too small\nfor the rotated font. Printing to the rotated console with a high-enough\ncharacter code will overflow the font buffer.\n\nv2:\n- fix typos in commit message(CVE-2026-46191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: fix buffer size clamping order\n\nIn vsock_update_buffer_size(), the buffer size was being clamped to the\nmaximum first, and then to the minimum. If a user sets a minimum buffer\nsize larger than the maximum, the minimum check overrides the maximum\ncheck, inverting the constraint.\n\nThis breaks the intended socket memory boundaries by allowing the\nvsk-\u0026gt;buffer_size to grow beyond the configured vsk-\u0026gt;buffer_max_size.\n\nFix this by checking the minimum first, and then the maximum. This\nensures the buffer size never exceeds the buffer_max_size.(CVE-2026-46234)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_uart: fix UAFs and race conditions in close and init paths\n\nVulnerabilities leading to Use-After-Free (UAF) and Null Pointer\nDereference (NPD) conditions were observed in the lifecycle management\nof hci_uart.\n\nThe primary issue arises because the workqueues (init_ready and\nwrite_work) are only flushed/cancelled if the HCI_UART_PROTO_READY\nflag is set during TTY close. If a hangup occurs before setup completes,\nhci_uart_tty_close() skips the teardown of these workqueues and\nproceeds to free the `hu` struct. When the scheduled work executes\nlater, it blindly dereferences the freed `hu` struct.\n\nFurthermore, several data races and UAFs were identified in the teardown\nsequence:\n1. Calling hci_uart_flush() from hci_uart_close() without effectively\n   disabling write_work causes a race condition where both can concurrently\n   double-free hu-\u0026gt;tx_skb. This happens because protocol timers can\n   concurrently invoke hci_uart_tx_wakeup() and requeue write_work.\n2. Calling hci_free_dev(hdev) before hu-\u0026gt;proto-\u0026gt;close(hu) causes a UAF\n   when vendor specific protocol close callbacks dereference hu-\u0026gt;hdev.\n3. In the initialization error paths, failing to take the proto_lock\n   write lock before clearing PROTO_READY leads to races with active\n   readers. Additionally, hci_uart_tty_receive() accesses hu-\u0026gt;hdev\n   outside the read lock, leading to UAFs if the initialization error\n   path frees hdev concurrently.\n\nFix these synchronization and lifecycle issues by:\n1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first,\n   followed immediately by a cancel_work_sync(\u0026amp;hu-\u0026gt;write_work). Clearing\n   the flag locks out concurrent protocol timers from successfully invoking\n   hci_uart_tx_wakeup(), effectively rendering the cancellation permanent\n   and preventing the tx_skb double-free.\n2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip\n   hu-\u0026gt;proto-\u0026gt;flush(). This is perfectly safe in the tty_close path\n   because hu-\u0026gt;proto-\u0026gt;close() executes shortly after, which intrinsically\n   purges all protocol SKB queues and tears down the state.\n3. Relocating hu-\u0026gt;proto-\u0026gt;close(hu) strictly prior to hci_free_dev(hdev)\n   across all close and error paths to prevent vendor-level UAFs.\n4. Moving the hdev-\u0026gt;stat.byte_rx increment in hci_uart_tty_receive()\n   inside the proto_lock read-side critical section to safely synchronize\n   with device unregistration.\n5. Adding cancel_work_sync(\u0026amp;hu-\u0026gt;write_work) to hci_uart_close() to safely\n   flush the workqueue before hci_uart_flush() is invoked via the HCI core.\n6. Utilizing cancel_work_sync() instead of disable_work_sync() across\n   all paths to prevent permanently breaking user-space retry capabilities.(CVE-2026-46275)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: terminate the cached volume label after UTF-8 conversion\n\nntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s()\nand stores the result in sbi-\u0026gt;volume.label. The converted label is later\nexposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only\nreturns the number of bytes written and does not add a trailing NUL.\n\nIf the converted label fills the entire fixed buffer,\nntfs3_label_show() can read past the end of sbi-\u0026gt;volume.label while\nlooking for a terminator.\n\nTerminate the cached label explicitly after a successful conversion and\nclamp the exact-full case to the last byte of the buffer.(CVE-2026-53023)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2/dlm: validate qr_numregions in dlm_match_regions()\n\nPatch series \u0026quot;ocfs2/dlm: fix two bugs in dlm_match_regions()\u0026quot;.\n\nIn dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGION\nnetwork message is used to drive loops over the qr_regions buffer without\nsufficient validation.  This series fixes two issues:\n\n- Patch 1 adds a bounds check to reject messages where qr_numregions\n  exceeds O2NM_MAX_REGIONS. The o2net layer only validates message\n  byte length; it does not constrain field values, so a crafted message\n  can set qr_numregions up to 255 and trigger out-of-bounds reads past\n  the 1024-byte qr_regions buffer.\n\n- Patch 2 fixes an off-by-one in the local-vs-remote comparison loop,\n  which uses \u0026apos;\u0026lt;=\u0026apos; instead of \u0026apos;\u0026lt;\u0026apos;, reading one entry past the valid range\n  even when qr_numregions is within bounds.\n\n\nThis patch (of 2):\n\nThe qr_numregions field from a DLM_QUERY_REGION network message is used\ndirectly as loop bounds in dlm_match_regions() without checking against\nO2NM_MAX_REGIONS.  Since qr_regions is sized for at most O2NM_MAX_REGIONS\n(32) entries, a crafted message with qr_numregions \u0026gt; 32 causes\nout-of-bounds reads past the qr_regions buffer.\n\nAdd a bounds check for qr_numregions before entering the loops.(CVE-2026-53043)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet\n\nThe irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and\nscheduled when RTL_IMR_BCNINT interrupt is triggered by hardware.\nBut it is never killed in rtl_pci_deinit(). When the rtlwifi card\nprobe fails or is being detached, the ieee80211_hw is deallocated.\nHowever, irq_prepare_bcn_tasklet may still be running or pending,\nleading to use-after-free when the freed ieee80211_hw is accessed\nin _rtl_pci_prepare_bcn_tasklet().\n\nSimilar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to\nensure that irq_prepare_bcn_tasklet is properly terminated before\nthe ieee80211_hw is released.\n\nThe issue was identified through static analysis.(CVE-2026-53112)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus\u0026apos; match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-53120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip_gre: require CAP_NET_ADMIN in the device netns for changelink\n\nA tunnel changelink() operates on at most two netns, dev_net(dev) and\nthe tunnel link netns t-\u0026gt;net. They differ once the device is created in\nor moved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t-\u0026gt;net can rewrite a tunnel that\nlives in t-\u0026gt;net.\n\nAdd rtnl_dev_link_net_capable() next to rtnl_get_net_ns_capable() in\nnet/core/rtnetlink.c. It requires CAP_NET_ADMIN in the link netns and is\nskipped when the link netns is dev_net(dev), where the rtnl path already\nchecked it. The other patches in this series use the same helper.\n\nGate ipgre_changelink() and erspan_changelink() with it, at the top of\nthe op before any attribute is parsed, because the parsers update live\ntunnel fields first. ipgre_netlink_parms() sets t-\u0026gt;collect_md before\nip_tunnel_changelink() runs.\n\nCommit 8b484efd5cb4 (\u0026quot;ip6: vti: Use ip6_tnl.net in\nvti6_siocdevprivate().\u0026quot;) added the same check on the ioctl path. This\nadds it on RTM_NEWLINK.(CVE-2026-63829)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: validate extension header length before copying to cmsg\n\nip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR}\ncmsgs (and their IPV6_2292* legacy counterparts) by trusting the\non-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length.\nThe length was validated only at parse time (ipv6_parse_hopopts(),\netc.).  An nftables payload-write expression can rewrite hdrlen after\nparsing and before the skb reaches recvmsg; the write itself is\nin-bounds but put_cmsg() then reads up to ((hdrlen+1) \u0026lt;\u0026lt; 3) = 2040\nbytes from an 8-byte header.  nftables is reachable from an\nunprivileged user namespace, so this is an unprivileged\nslab-out-of-bounds read:\n\n  BUG: KASAN: slab-out-of-bounds in put_cmsg+0x3ac/0x540\n   put_cmsg+0x3ac/0x540\n   udpv6_recvmsg+0xca0/0x1250\n   sock_recvmsg+0xdf/0x190\n   ____sys_recvmsg+0x1b1/0x620\n\nAdd ipv6_get_exthdr_len() which validates that at least two bytes\nare accessible before reading the hdrlen field, then checks the\ncomputed length against skb_tail_pointer(skb), returning 0 on\nfailure.  Extension headers are kept in the linear skb area by\npskb_may_pull() during input, so skb_tail_pointer() is the correct\nbound.\n\nUse ipv6_get_exthdr_len() at all non-AH call sites: the five\nstandalone cmsg blocks (HbH, 2292HbH, 2292DSTOPTS x2, 2292RTHDR)\nand the three standard cases in the extension-header walk loop\n(DSTOPTS, ROUTING, default).  AH retains an inline bounds check\nbecause its length formula differs ((ptr[1]+2)\u0026lt;\u0026lt;2).\n\nThe walk loop also gets a pre-read bounds check at the top to\nvalidate ptr before any case accesses ptr[0] or ptr[1].\n\nWhen the walk loop detects a corrupted header, return from the\nfunction instead of continuing to process later socket options.(CVE-2026-63920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().\n\nAfter patch 1/2 in this series, vti6_update() unlinks and relinks\nthe tunnel through t-\u0026gt;net. vti6_siocdevprivate() still uses\ndev_net(dev) for the collision lookup. For a tunnel moved through\nIFLA_NET_NS_FD, dev_net(dev) is the new netns, not t-\u0026gt;net.\n\nSIOCCHGTUNNEL on a migrated tunnel then runs:\n\n  net = dev_net(dev)                    /* migrated netns */\n  t   = vti6_locate(net, \u0026amp;p1, false)    /* misses target in t-\u0026gt;net */\n  ...\n  t   = netdev_priv(dev)\n  vti6_update(t, \u0026amp;p1, false)            /* mutates t-\u0026gt;net\u0026apos;s hash */\n\nA caller in the migrated netns picks params that match a tunnel\nin the creation netns. The lookup in dev_net(dev) finds nothing.\nvti6_update() prepends the migrated tunnel at the head of the\ncreation netns hash bucket for those params. Later lookups in\nthe creation netns resolve to the migrated device. xfrm receive\ndelivers the matched packets through a device the caller controls.\n\nReachable from an unprivileged user namespace (unshare --user\n--map-root-user --net). Cross tenant scope on container hosts.\n\nSwitch the SIOCCHGTUNNEL path on a non fallback device to use\nt-\u0026gt;net for the lookup. The lookup now matches the netns\nvti6_update() operates on.\n\nAlso add ns_capable(self-\u0026gt;net-\u0026gt;user_ns, CAP_NET_ADMIN) before\nthe lookup. The check at the top of the case is against\ndev_net(dev)-\u0026gt;user_ns, which after migration is the attacker\u0026apos;s\nnetns. A caller there can pick params absent from self-\u0026gt;net,\nthe lookup returns NULL, t becomes self, and vti6_update()\ninserts the device into the creation netns hash. The new check\nrequires CAP_NET_ADMIN in the creation netns user_ns too.\n\nSIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep\ndev_net(dev), which equals init_net there.(CVE-2026-63921)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: synproxy: refresh tcphdr after skb_ensure_writable\n\nsynproxy_tstamp_adjust() rewrites the TCP timestamp option in place\nand then patches the TCP checksum via inet_proto_csum_replace4() on\nthe caller-supplied tcphdr pointer.  Both ipv4_synproxy_hook() and\nipv6_synproxy_hook() obtain that pointer with skb_header_pointer()\nbefore calling in, so it may either alias skb-\u0026gt;head directly or\npoint at the caller\u0026apos;s on-stack _tcph buffer.\n\nBetween obtaining the pointer and using it, the function calls\nskb_ensure_writable(skb, optend), which on a cloned or non-linear\nskb invokes pskb_expand_head() and frees the old skb-\u0026gt;head.  After\nthat point the cached th is stale:\n\n    caller (ipv[46]_synproxy_hook)\n      th = skb_header_pointer(skb, ..., \u0026amp;_tcph)\n      synproxy_tstamp_adjust(skb, protoff, th, ...)\n        skb_ensure_writable(skb, optend)\n          pskb_expand_head()        /* kfree(old skb-\u0026gt;head) */\n        ...\n        inet_proto_csum_replace4(\u0026amp;th-\u0026gt;check, ...)\n                                    /* writes into freed head, or\n                                       into the caller\u0026apos;s stack copy\n                                       leaving the on-wire checksum\n                                       stale */\n\nThe option bytes are written through skb-\u0026gt;data and are fine; only\nthe checksum update goes through th and so lands in the wrong\nplace.  The result is either a write into freed slab memory or a\npacket leaving with a checksum that does not match its payload.\n\nFix by re-deriving th from skb-\u0026gt;data + protoff immediately after\nskb_ensure_writable() succeeds, so the subsequent checksum update\ntargets the linear, writable header.(CVE-2026-64007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: raw: reject IP_HDRINCL packets with ihl \u0026lt; 5\n\nraw_send_hdrinc() validates that the caller-supplied IPv4 header\nfits within the message length:\n\n    iphlen = iph-\u0026gt;ihl * 4;\n    err = -EINVAL;\n    if (iphlen \u0026gt; length)\n        goto error_free;\n\n    if (iphlen \u0026gt;= sizeof(*iph)) {\n        /* fix up saddr, tot_len, id, csum, transport_header */\n    }\n\nIt does not, however, reject ihl \u0026lt; 5.  For such a packet the\n\u0026quot;if (iphlen \u0026gt;= sizeof(*iph))\u0026quot; branch is skipped, leaving the\ncrafted iphdr untouched, but the packet is still handed to\n__ip_local_out() and onward.  Downstream consumers that read\niph-\u0026gt;ihl assume a sane value: net/ipv4/ah4.c:ah_output() in\nparticular subtracts sizeof(struct iphdr) from top_iph-\u0026gt;ihl * 4\nand passes the (signed-int-negative, then cast to size_t)\nresult to memcpy(), producing an OOB access of length close to\nSIZE_MAX and a host kernel panic.\n\nAn IPv4 header with ihl \u0026lt; 5 is malformed by definition (RFC 791:\n\u0026quot;Internet Header Length is the length of the internet header in\n32 bit words ... Note that the minimum value for a correct header\nis 5.\u0026quot;).  The kernel should not be willing to inject such a\npacket into its own output path.\n\nReject \u0026quot;iphlen \u0026lt; sizeof(*iph)\u0026quot; alongside the existing\n\u0026quot;iphlen \u0026gt; length\u0026quot; check.  This matches the principle that locally\nconstructed packets that re-enter the IP stack must pass the same\nbasic sanity tests that a foreign packet would be subjected to.\n\nOnce this lands, the \u0026quot;if (iphlen \u0026gt;= sizeof(*iph))\u0026quot; wrapper around\nthe fixup branch becomes redundant; left in place to keep the\npatch minimal and backport-friendly.  A follow-up can unwrap it.\n\nNote that commit 86f4c90a1c5c (\u0026quot;ipv4, ipv6: ensure raw socket\nmessage is big enough to hold an IP header\u0026quot;) ensures the message\nbuffer is large enough to hold an iphdr, but does not constrain\nthe self-reported iph-\u0026gt;ihl.\n\nReachability: the malformed packet source is any caller with\nCAP_NET_RAW, including an unprivileged process in a user+net\nnamespace on a kernel with CONFIG_USER_NS=y.  The reproduced AH\ncrash also requires a matching xfrm AH policy on the outgoing\nroute; a container granted CAP_NET_ADMIN can install that state\nand policy in its netns.  Loopback bypasses xfrm_output, so the\ntrigger uses a real netdev.\n\nReproduced on UML + KASAN: kernel-mode fault at addr 0x0 with\nmemcpy_orig at the crash site.  Same shape reproduces inside a\nrootless Docker container with --cap-add NET_ADMIN on a stock\ndistro kernel.(CVE-2026-64114)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: asihpi: Fix potential OOB array access at reading cache\n\nfind_control() to retrieve a cached info accesses the array with the\ngiven index blindly, which may lead to an OOB array access.\nAdd a sanity check for avoiding it.(CVE-2026-64133)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: re-lock request before returning from fuse_ref_folio()\n\nfuse_ref_folio() unlocks the request but does not re-lock it before\nreturning. fuse_chan_abort() can end the request and the async end\ncallback (eg fuse_writepage_free()) can free the args while the\nsubsequent copy chain logic after fuse_ref_folio() accesses them,\nleading to use-after-free issues.\n\nFix this by locking the request in fuse_ref_folio() before returning.(CVE-2026-64266)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv4: bound TCP reordering sysctl writes and MTU probe sizes\n\nReject invalid `net.ipv4.tcp_reordering` values before they reach TCP\nsocket state. The sysctl is stored as an `int` but copied into the\n`u32` `tp-\u0026gt;reordering` field for new sockets, so negative writes wrap\nto large values.\n\nWith `tcp_mtu_probing=2`, the wrapped value can overflow the\n`tcp_mtu_probe()` size calculation and drive the MTU probing path into\nan out-of-bounds read. Route `tcp_reordering` writes through\n`proc_dointvec_minmax()` and require it to be at least 1. Also require\n`tcp_max_reordering` to be at least 1 so the configured maximum cannot\nbecome negative either.\n\nWhen registering the table for a non-init network namespace, relocate\n`extra2` pointers that refer into `init_net.ipv4` so the\n`tcp_reordering` upper bound follows that namespace\u0026apos;s\n`tcp_max_reordering`.\n\nHarden `tcp_mtu_probe()` itself by computing `size_needed` as `u64`.\nThis keeps the send queue and window checks from being bypassed through\nsigned integer overflow.(CVE-2026-64422)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: af_key: initialize alg_key_len for IPComp states\n\npfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by\nallocating x-\u0026gt;calg and copying only the algorithm name:\n\n\tx-\u0026gt;calg = kmalloc_obj(*x-\u0026gt;calg);\n\tif (!x-\u0026gt;calg) {\n\t\terr = -ENOMEM;\n\t\tgoto out;\n\t}\n\tstrcpy(x-\u0026gt;calg-\u0026gt;alg_name, a-\u0026gt;name);\n\tx-\u0026gt;props.calgo = sa-\u0026gt;sadb_sa_encrypt;\n\nUnlike the authentication (x-\u0026gt;aalg) and encryption (x-\u0026gt;ealg) branches of\nthe same function, the compression branch never initializes\ncalg-\u0026gt;alg_key_len.  IPComp carries no key and the allocation only\nreserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field\nis left containing uninitialized slab data.\n\ncalg-\u0026gt;alg_key_len is later used as a length by xfrm_algo_clone() when an\nIPComp state is cloned during XFRM_MSG_MIGRATE:\n\n\txfrm_state_migrate()\n\t  xfrm_state_clone_and_setup()\n\t    x-\u0026gt;calg = xfrm_algo_clone(orig-\u0026gt;calg);\n\t      kmemdup(orig, xfrm_alg_len(orig));\n\nwhere xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8.  With\na non-zero garbage alg_key_len, kmemdup() reads past the end of the\n68-byte calg object.  Adding an IPComp SA via PF_KEY and then migrating\nit triggers (net-next, KASAN, init_on_alloc=0):\n\n  BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60\n  Read of size 4164 at addr ff11000025a74980 by task diag2/9287\n  CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x10e/0x1f0\n   print_report+0xf7/0x600\n   kasan_report+0xe4/0x120\n   kasan_check_range+0x105/0x1b0\n   __asan_memcpy+0x23/0x60\n   kmemdup_noprof+0x44/0x60\n   xfrm_state_migrate+0x70a/0x1da0\n   xfrm_migrate+0x753/0x18a0\n   xfrm_do_migrate+0xb47/0xf10\n   xfrm_user_rcv_msg+0x411/0xb50\n   netlink_rcv_skb+0x158/0x420\n   xfrm_netlink_rcv+0x71/0x90\n   netlink_unicast+0x584/0x850\n   netlink_sendmsg+0x8b0/0xdc0\n   ____sys_sendmsg+0x9f7/0xb90\n   ___sys_sendmsg+0x134/0x1d0\n   __sys_sendmsg+0x16d/0x220\n   do_syscall_64+0x116/0x7d0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n   \u0026lt;/TASK\u0026gt;\n\n  Allocated by task 9287:\n   kasan_save_stack+0x33/0x60\n   kasan_save_track+0x14/0x30\n   __kasan_kmalloc+0xaa/0xb0\n   pfkey_add+0x2652/0x2ea0\n   pfkey_process+0x6d0/0x830\n   pfkey_sendmsg+0x42c/0x850\n   __sys_sendto+0x461/0x4b0\n   __x64_sys_sendto+0xe0/0x1c0\n   do_syscall_64+0x116/0x7d0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n  The buggy address belongs to the object at ff11000025a74980\n   which belongs to the cache kmalloc-96 of size 96\n  The buggy address is located 0 bytes inside of\n   allocated 68-byte region [ff11000025a74980, ff11000025a749c4)\n\nDepending on the uninitialized value the same field can instead request\nan oversized kmemdup() allocation and make the migration clone fail.\n\nThe XFRM netlink path is not affected: verify_one_alg() rejects an\nXFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via\nXFRM_MSG_NEWSA is always self-consistent.\n\nInitialize calg-\u0026gt;alg_key_len to 0, matching the aalg/ealg branches.(CVE-2026-64436)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/edid: fix OOB read in drm_parse_tiled_block()\n\ndrm_parse_tiled_block() casts the DisplayID block to a\nstruct displayid_tiled_block and reads the full fixed layout up to\ntile-\u0026gt;topology_id[7] without checking block-\u0026gt;num_bytes. The DisplayID\niterator only validates the declared payload length, so a crafted EDID\ncan advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or\nDATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at\nthe end of a DisplayID extension. The read then runs past the end of the\nexact-sized kmemdup()\u0026apos;d EDID allocation, a heap out-of-bounds read.\n\nReject blocks shorter than the spec\u0026apos;s 22-byte tiled payload before\nreading the fixed struct, as drm_parse_vesa_mso_data() already does.\n\n  BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update\n  Read of size 2 at addr ffff888010077700 by task exploit/147\n   dump_stack_lvl (lib/dump_stack.c:94 ...)\n   print_report (mm/kasan/report.c:378 ...)\n   kasan_report (mm/kasan/report.c:595)\n   drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581)\n   bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574)\n   drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426)\n   status_store (drivers/gpu/drm/drm_sysfs.c:219)\n   ...\n   vfs_write (fs/read_write.c:595 fs/read_write.c:688)\n   ksys_write (fs/read_write.c:740)(CVE-2026-64546)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: qca: fix NVM tag length underflow in TLV parser\n\nIn the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is\n\u0026quot;while (idx \u0026lt; length - sizeof(struct tlv_type_nvm))\u0026quot;. \u0026quot;length\u0026quot; is a signed\nint from the firmware TLV header and sizeof(struct tlv_type_nvm) is a\nsize_t (12), so \u0026quot;length\u0026quot; is converted to size_t and any firmware-supplied\n\u0026quot;length\u0026quot; \u0026lt; 12 makes the subtraction wrap to a huge value. The loop body\nthen reads a 12-byte struct tlv_type_nvm past the end of the short\nvmalloc\u0026apos;d firmware buffer (and the EDL_TAG_ID_* handlers can write past it).\n\nRewrite the bound as \u0026quot;idx + sizeof(struct tlv_type_nvm) \u0026lt;= length\u0026quot;; both\noperands are non-negative, so it no longer underflows and a \u0026quot;length\u0026quot; too\nsmall for one record correctly skips the loop.\n\n  BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421)\n  Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52\n  Workqueue: hci0 hci_power_on\n  Call Trace:\n   ...\n   kasan_report (mm/kasan/report.c:595)\n   qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617)\n   qca_uart_setup (drivers/bluetooth/btqca.c:948)\n   qca_setup (drivers/bluetooth/hci_qca.c:2029)\n   hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438)\n   hci_dev_open_sync (net/bluetooth/hci_sync.c:5227)\n   hci_power_on (net/bluetooth/hci_core.c:920)\n   process_one_work (kernel/workqueue.c:3322)\n   worker_thread (kernel/workqueue.c:3486)\n   kthread (kernel/kthread.c:436)\n   ret_from_fork (arch/x86/kernel/process.c:158)\n   ret_from_fork_asm (arch/x86/entry/entry_64.S:245)(CVE-2026-64573)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()\n\nceph_handle_caps() reads snap_trace_len from the wire-format\nceph_mds_caps header and uses it unconditionally to build a fake\nend pointer (snaptrace + snaptrace_len) that is later handed to\nceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case:\n\n    snaptrace     = h + 1;\n    snaptrace_len = le32_to_cpu(h-\u0026gt;snap_trace_len);\n    p             = snaptrace + snaptrace_len;\n    ...\n    case CEPH_CAP_OP_IMPORT:\n        if (snaptrace_len) {\n            ...\n            if (ceph_update_snap_trace(mdsc, snaptrace,\n                                       snaptrace + snaptrace_len,\n                                       false, \u0026amp;realm)) { ... }\n\nceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm\nfrom snaptrace using ceph_decode_need(\u0026amp;p, e, sizeof(*ri), bad)\nwith the attacker-supplied fake end e == snaptrace + snaptrace_len.\nWith snaptrace_len == 0xFFFFFFFF the bound check is trivially\nsatisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past\nthe legitimate msg-\u0026gt;front buffer, and ri-\u0026gt;num_snaps /\nri-\u0026gt;num_prior_parent_snaps then drive further out-of-bounds\nreads of the encoded snap arrays.\n\nThe eleven msg_version \u0026gt;= 2 .. msg_version \u0026gt;= 12 decoder blocks\nabove the op switch each catch this OOB through their\nceph_decode_*_safe() / ceph_decode_need() helpers, but they sit\nbehind a hdr.version-gated if, so a malicious or compromised\nMDS that sets msg-\u0026gt;hdr.version = 1 reaches the IMPORT path with\nno version-gated decoder having validated snap_trace_len. The\nshape has been present since ceph_handle_caps() was introduced.\n\nValidate snap_trace_len against the message front buffer before\nconsuming it, using the canonical ceph_decode_need() / ceph_has_room()\nhelper.  The helper bounds the length with subtraction (n \u0026lt;= end - p,\nguarded by end \u0026gt;= p) rather than pointer addition, so it is wrap-safe\nfor the attacker-controlled u32 length on 32-bit builds where\np + snap_trace_len could overflow the address space.  This matches the\nrest of the ceph decode path (e.g. the pool_ns_len check a few lines\nbelow), and the existing goto bad cleanup already covers this exit\npath.(CVE-2026-68160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Make the TPM character devices non-seekable\n\nThe TPM character devices expose a sequential command/response\ninterface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE\nenabled.\n\nAfter a command leaves a response pending, pread(fd, buf, 16, 0x1400)\npasses 0x1400 as *off to tpm_common_read(). The transfer length is\nbounded by response_length, but the offset is used unchecked when\nforming data_buffer + *off. A sufficiently large offset therefore causes\nan out-of-bounds heap read through copy_to_user() and, if the copy\nsucceeds, an out-of-bounds zero-write through the following memset().\n\nPositional I/O does not provide coherent semantics for this interface.\nAn arbitrary pread offset cannot represent how much of a response has\nbeen consumed sequentially. The write callback always stores a command\nat the start of data_buffer, while pwrite() does not update file-\u0026gt;f_pos\nand can leave the sequential read cursor stale.\n\nCall nonseekable_open() from both open handlers. This removes\nFMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to\nfail with -ESPIPE before reaching the TPM callbacks, and explicitly\nmarks the files non-seekable. Normal read() and write() continue to use\nthe existing sequential f_pos cursor, leaving the response state machine\nunchanged.\n\nTested on Linux 6.12 with KASAN and a swtpm TPM2 device:\n\n - sequential partial reads returned the complete response\n - pread() and preadv() with offset 0x1400 returned -ESPIPE\n - pwrite() and pwritev() with offset zero returned -ESPIPE\n - the pending response remained intact after the rejected operations\n - a subsequent normal command/response cycle completed normally\n - no KASAN report was produced.(CVE-2026-72135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_u32: reject invalid shift counts\n\nu32_match_it() executes rule-supplied shift operands on a 32-bit\nvalue. A malformed u32 rule can provide a shift count of 32 or more,\ntriggering an undefined shift out-of-bounds during packet evaluation.\n\nValidate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in\nu32_mt_checkentry() and reject malformed rules before they reach the\npacket path.(CVE-2026-72350)",
  "id": "OESA-2026-3532",
  "modified": "2026-08-30T04:15:17Z",
  "published": "2026-08-30T04:15:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3532"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49289"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37991"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68190"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23102"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43373"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46054"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46191"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46234"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46275"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53023"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53043"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53112"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53120"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63829"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63920"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63921"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64007"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64114"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64133"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64266"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64422"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64436"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64546"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64573"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68160"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72135"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72350"
    }
  ],
  "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-2022-49289",
    "CVE-2025-37991",
    "CVE-2025-68190",
    "CVE-2026-23102",
    "CVE-2026-43373",
    "CVE-2026-46054",
    "CVE-2026-46191",
    "CVE-2026-46234",
    "CVE-2026-46275",
    "CVE-2026-53023",
    "CVE-2026-53043",
    "CVE-2026-53112",
    "CVE-2026-53120",
    "CVE-2026-63829",
    "CVE-2026-63920",
    "CVE-2026-63921",
    "CVE-2026-64007",
    "CVE-2026-64114",
    "CVE-2026-64133",
    "CVE-2026-64266",
    "CVE-2026-64422",
    "CVE-2026-64436",
    "CVE-2026-64546",
    "CVE-2026-64573",
    "CVE-2026-68160",
    "CVE-2026-72135",
    "CVE-2026-72350"
  ]
}

OPENSUSE-SU-2026:11476-1

Vulnerability from csaf_opensuse - Published: 2026-08-09 00:00 - Updated: 2026-09-26 08:35

Summary

kernel-devel-7.1.7-1.1 on GA media

Severity

Moderate

Scope

351 vulnerabilities in this advisory, including CVE-2026-64546.

CVE-2026-64546

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 16 products

Open the full advisory

OPENSUSE-SU-2026:21910-1

Vulnerability from csaf_opensuse - Published: 2026-09-22 15:26 - Updated: 2026-10-02 10:47

Summary

Security update for the Linux Kernel

Severity

Important

Scope

885 vulnerabilities in this advisory, including CVE-2026-64546.

CVE-2026-64546

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 136 products

Open the full advisory

SUSE-SU-2026:23477-1

Vulnerability from csaf_suse - Published: 2026-09-08 12:54 - Updated: 2026-10-02 10:44

Summary

Security update for the Linux Kernel

Severity

Important

Scope

588 vulnerabilities in this advisory, including CVE-2026-64546.

CVE-2026-64546

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 4 products

Open the full advisory

SUSE-SU-2026:23481-1

Vulnerability from csaf_suse - Published: 2026-09-08 13:00 - Updated: 2026-10-02 10:44

Summary

Security update for the Linux Kernel

Severity

Important

Scope

588 vulnerabilities in this advisory, including CVE-2026-64546.

CVE-2026-64546

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 11 products

Open the full advisory

SUSE-SU-2026:23528-1

Vulnerability from csaf_suse - Published: 2026-09-08 10:34 - Updated: 2026-10-02 10:44

Summary

Security update for the Linux Kernel

Severity

Important

Scope

588 vulnerabilities in this advisory, including CVE-2026-64546.

CVE-2026-64546

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 7 products

Open the full advisory

SUSE-SU-2026:23529-1

Vulnerability from csaf_suse - Published: 2026-09-08 11:00 - Updated: 2026-10-02 10:44

Summary

Security update for the Linux Kernel

Severity

Important

Scope

588 vulnerabilities in this advisory, including CVE-2026-64546.

CVE-2026-64546

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 17 products

Open the full advisory

SUSE-SU-2026:23881-1

Vulnerability from csaf_suse - Published: 2026-09-22 13:18 - Updated: 2026-10-02 10:44

Summary

Security update for the Linux Kernel

Severity

Important

Scope

885 vulnerabilities in this advisory, including CVE-2026-64546.

CVE-2026-64546

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 8 products

Open the full advisory

SUSE-SU-2026:23887-1

Vulnerability from csaf_suse - Published: 2026-09-22 14:23 - Updated: 2026-10-02 10:44

Summary

Security update for the Linux Kernel

Severity

Important

Scope

885 vulnerabilities in this advisory, including CVE-2026-64546.

CVE-2026-64546

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 28 products

Open the full advisory

SUSE-SU-2026:23897-1

Vulnerability from csaf_suse - Published: 2026-09-22 13:58 - Updated: 2026-10-02 10:44

Summary

Security update for the Linux Kernel

Severity

Important

Scope

885 vulnerabilities in this advisory, including CVE-2026-64546.

CVE-2026-64546

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 9 products

Open the full advisory

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
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.

Action not permitted

CVE-2026-64546 (GCVE-0-2026-64546)

OESA-2026-3532 (CVE-2022-49289)

Tags

Sightings

Nomenclature

Related by attack behaviour