Vulnerability-Lookup

CVE-2026-64539 (GCVE-0-2026-64539)

Vulnerability from cvelistv5 – Published: 2026-07-27 20:10 – Updated: 2026-10-21 12:43

Title

Bluetooth: eir: Fix stack OOB write when prepending the Flags AD

Summary

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix stack OOB write when prepending the Flags AD eir_create_adv_data() builds the advertising data into a fixed-size buffer ("size", 31 for the legacy path). It may prepend a 3-byte "Flags" AD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies the per-instance data without checking that it still fits: memcpy(ptr, adv->adv_data, adv->adv_data_len); tlv_data_max_len() only reserves those 3 bytes when the user-supplied flags carry a managed-flags bit, so an instance added with flags == 0 is accepted with adv_data_len up to the full buffer. At advertise time the flags are still prepended, and the memcpy() writes 3 + adv_data_len bytes into the size-byte buffer: BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301) Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65 Workqueue: hci0 hci_cmd_sync_work __asan_memcpy (mm/kasan/shadow.c:106) eir_create_adv_data (net/bluetooth/eir.c:301) hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310) hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817) hci_cmd_sync_work (net/bluetooth/hci_sync.c:332) This frame has 1 object: [32, 64) 'cp' The "Flags" structure is added by the kernel, not requested by userspace, so only prepend it when it fits together with the instance advertising data; when there is no room for both, drop the flags rather than the user-provided data. Reachable by a local user with CAP_NET_ADMIN owning an LE-only controller on the legacy advertising path.

Severity

7.8 (High)


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

SSVC

Exploitation: none Automatable: no Technical Impact: total

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-16 15:42 UTC

CWE

CWE-121 - Stack-based Buffer Overflow

Assigner

Linux CNA under the mitre root

CNA scorecard D 53/100 over 6653 records in the last 180 days details

References

6 references

URL	Tags
https://git.kernel.org/stable/c/0f0b6232af56441d0…
https://git.kernel.org/stable/c/9174992ee1045c9c9…
https://git.kernel.org/stable/c/09301f1fdf2aef8cc…
https://git.kernel.org/stable/c/f1b4df9c260c51726…
https://git.kernel.org/stable/c/57077eeb586c42f12…
https://git.kernel.org/stable/c/6f5fb689fdf80bdd1…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: b44133ff03be30b55f23036e62f403a3f7784fce , < 0f0b6232af56441d0a2dcb173cc4f8d8aab39014 (git) Affected: b44133ff03be30b55f23036e62f403a3f7784fce , < 9174992ee1045c9c96e53eecda64f49dd7e8fbba (git) Affected: b44133ff03be30b55f23036e62f403a3f7784fce , < 09301f1fdf2aef8cce34d0c4650c30e7edb1ced9 (git) Affected: b44133ff03be30b55f23036e62f403a3f7784fce , < f1b4df9c260c51726da2e86e19322825fddeefd0 (git) Affected: b44133ff03be30b55f23036e62f403a3f7784fce , < 57077eeb586c42f124bc09e018449362223067b3 (git) Affected: b44133ff03be30b55f23036e62f403a3f7784fce , < 6f5fb689fdf80bdd143f22a502f9eb1f3c85e286 (git)	guessed
Linux	Linux	Affected: 4.1 Unaffected: 0 , < 4.1 (semver) Unaffected: 6.1.178 , ≤ 6.1.* (semver) Unaffected: 6.6.160 , ≤ 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": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-64539",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-16T15:42:00.875042Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-121",
                "description": "CWE-121 Stack-based Buffer Overflow",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-19T20:48:39.300Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/bluetooth/eir.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "0f0b6232af56441d0a2dcb173cc4f8d8aab39014",
              "status": "affected",
              "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
              "versionType": "git"
            },
            {
              "lessThan": "9174992ee1045c9c96e53eecda64f49dd7e8fbba",
              "status": "affected",
              "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
              "versionType": "git"
            },
            {
              "lessThan": "09301f1fdf2aef8cce34d0c4650c30e7edb1ced9",
              "status": "affected",
              "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
              "versionType": "git"
            },
            {
              "lessThan": "f1b4df9c260c51726da2e86e19322825fddeefd0",
              "status": "affected",
              "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
              "versionType": "git"
            },
            {
              "lessThan": "57077eeb586c42f124bc09e018449362223067b3",
              "status": "affected",
              "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
              "versionType": "git"
            },
            {
              "lessThan": "6f5fb689fdf80bdd143f22a502f9eb1f3c85e286",
              "status": "affected",
              "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/bluetooth/eir.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.1"
            },
            {
              "lessThan": "4.1",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.178",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.160",
              "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": "6.1.178",
                  "versionStartIncluding": "4.1",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.160",
                  "versionStartIncluding": "4.1",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.97",
                  "versionStartIncluding": "4.1",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.40",
                  "versionStartIncluding": "4.1",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1.5",
                  "versionStartIncluding": "4.1",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2",
                  "versionStartIncluding": "4.1",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: eir: Fix stack OOB write when prepending the Flags AD\n\neir_create_adv_data() builds the advertising data into a fixed-size\nbuffer (\"size\", 31 for the legacy path). It may prepend a 3-byte \"Flags\"\nAD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies\nthe per-instance data without checking that it still fits:\n\n\tmemcpy(ptr, adv-\u003eadv_data, adv-\u003eadv_data_len);\n\ntlv_data_max_len() only reserves those 3 bytes when the user-supplied\nflags carry a managed-flags bit, so an instance added with flags == 0 is\naccepted with adv_data_len up to the full buffer. At advertise time the\nflags are still prepended, and the memcpy() writes 3 + adv_data_len\nbytes into the size-byte buffer:\n\n  BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)\n  Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65\n  Workqueue: hci0 hci_cmd_sync_work\n   __asan_memcpy (mm/kasan/shadow.c:106)\n   eir_create_adv_data (net/bluetooth/eir.c:301)\n   hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)\n   hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)\n   hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)\n  This frame has 1 object:\n   [32, 64) \u0027cp\u0027\n\nThe \"Flags\" structure is added by the kernel, not requested by\nuserspace, so only prepend it when it fits together with the instance\nadvertising data; when there is no room for both, drop the flags rather\nthan the user-provided data.\n\nReachable by a local user with CAP_NET_ADMIN owning an LE-only\ncontroller on the legacy advertising path."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The overflow is driven entirely by locally supplied advertising data written to an AF_BLUETOOTH HCI control socket (MGMT_OP_ADD_ADVERTISING / ADD_EXT_ADV_DATA / MESH_SEND); no remote or adjacent Bluetooth peer can influence the length or contents. Consistent with the same-class CVE-2026-53209 and CVE-2026-64126, this is a local-only trigger.\nAC:L - The attacker fully controls both preconditions \u2014 submit an instance with flags==0 and adv_data_len at the maximum, containing no EIR_FLAGS element \u2014 and the kernel then deterministically prepends the 3-byte Flags AD on any LE-only controller. No race, no memory-layout luck, no retry needed.\nPR:L - Reaching the mgmt handler requires HCI_SOCK_TRUSTED, granted by CAP_NET_ADMIN, which is a delegated capability routinely held by the Bluetooth stack daemon rather than full system root, and this CNA scores the identical CAP_NET_ADMIN-gated Bluetooth mgmt paths (CVE-2026-64126, CVE-2026-53209, CVE-2026-31511) as PR:L. Choosing the higher-severity option where the privilege boundary is arguable.\nUI:N - The attacker issues the mgmt commands itself and the overflow fires from hci_cmd_sync_work when the instance is scheduled for advertising. No victim action of any kind is involved.\nS:U - The corruption is confined to the kernel\u0027s own stack within the same security authority; there is no VM, IOMMU, or sandbox boundary crossed.\nC:H - On the extended-advertising path the inflated length (254 \u003e 251) makes struct_size() copy 3 bytes of adjacent kernel stack past the DEFINE_FLEX pdu into the HCI command skb, which is exposed via the HCI monitor channel and handed to the controller for broadcast, and the stack corruption is generally leverageable for further disclosure.\nI:H - This is an out-of-bounds write of fully attacker-controlled bytes (the tail of the user-supplied adv_data) past a local stack object, and it additionally leaves hdev-\u003eadv_data_len set to a value larger than the data actually stored. An attacker-controlled linear stack overflow is treated as high integrity impact.\nA:H - Overwriting bytes immediately past the stack object corrupts adjacent frame state and, with CONFIG_STACKPROTECTOR, will trip __stack_chk_fail leading to a kernel panic; the reported KASAN stack-out-of-bounds confirms real memory corruption in hci_cmd_sync_work."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-21T12:43:26.591Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/0f0b6232af56441d0a2dcb173cc4f8d8aab39014"
        },
        {
          "url": "https://git.kernel.org/stable/c/9174992ee1045c9c96e53eecda64f49dd7e8fbba"
        },
        {
          "url": "https://git.kernel.org/stable/c/09301f1fdf2aef8cce34d0c4650c30e7edb1ced9"
        },
        {
          "url": "https://git.kernel.org/stable/c/f1b4df9c260c51726da2e86e19322825fddeefd0"
        },
        {
          "url": "https://git.kernel.org/stable/c/57077eeb586c42f124bc09e018449362223067b3"
        },
        {
          "url": "https://git.kernel.org/stable/c/6f5fb689fdf80bdd143f22a502f9eb1f3c85e286"
        }
      ],
      "title": "Bluetooth: eir: Fix stack OOB write when prepending the Flags AD",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-64539",
    "datePublished": "2026-07-27T20:10:33.363Z",
    "dateReserved": "2026-07-19T15:36:31.795Z",
    "dateUpdated": "2026-10-21T12:43:26.591Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-64539",
      "date": "2026-11-08",
      "epss": "0.00127",
      "percentile": "0.02421"
    },
    "microsoft_vex": {
      "current_release_date": "2026-11-07T01:49:35.000Z",
      "cve": "CVE-2026-64539",
      "id": "msrc_CVE-2026-64539",
      "initial_release_date": "2026-08-11T01:03:23.000Z",
      "product_status:fixed": "1",
      "product_status:known_affected": "5",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "Bluetooth: eir: Fix stack OOB write when prepending the Flags AD",
      "url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2026-64539.json",
      "version": "7"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "net/bluetooth/eir.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "0f0b6232af56441d0a2dcb173cc4f8d8aab39014",
                    "status": "affected",
                    "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "9174992ee1045c9c96e53eecda64f49dd7e8fbba",
                    "status": "affected",
                    "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "09301f1fdf2aef8cce34d0c4650c30e7edb1ced9",
                    "status": "affected",
                    "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "f1b4df9c260c51726da2e86e19322825fddeefd0",
                    "status": "affected",
                    "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "57077eeb586c42f124bc09e018449362223067b3",
                    "status": "affected",
                    "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "6f5fb689fdf80bdd143f22a502f9eb1f3c85e286",
                    "status": "affected",
                    "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "net/bluetooth/eir.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "4.1"
                  },
                  {
                    "lessThan": "4.1",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.178",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.160",
                    "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\nBluetooth: eir: Fix stack OOB write when prepending the Flags AD\n\neir_create_adv_data() builds the advertising data into a fixed-size\nbuffer (\"size\", 31 for the legacy path). It may prepend a 3-byte \"Flags\"\nAD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies\nthe per-instance data without checking that it still fits:\n\n\tmemcpy(ptr, adv-\u003eadv_data, adv-\u003eadv_data_len);\n\ntlv_data_max_len() only reserves those 3 bytes when the user-supplied\nflags carry a managed-flags bit, so an instance added with flags == 0 is\naccepted with adv_data_len up to the full buffer. At advertise time the\nflags are still prepended, and the memcpy() writes 3 + adv_data_len\nbytes into the size-byte buffer:\n\n  BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)\n  Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65\n  Workqueue: hci0 hci_cmd_sync_work\n   __asan_memcpy (mm/kasan/shadow.c:106)\n   eir_create_adv_data (net/bluetooth/eir.c:301)\n   hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)\n   hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)\n   hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)\n  This frame has 1 object:\n   [32, 64) \u0027cp\u0027\n\nThe \"Flags\" structure is added by the kernel, not requested by\nuserspace, so only prepend it when it fits together with the instance\nadvertising data; when there is no room for both, drop the flags rather\nthan the user-provided data.\n\nReachable by a local user with CAP_NET_ADMIN owning an LE-only\ncontroller on the legacy advertising path."
          }
        ],
        "id": "CVE-2026-64539",
        "lastModified": "2026-11-03T18:15:39.353",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-64539",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-16T15:42:00.875042Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-07-27T21:17:06.277",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/09301f1fdf2aef8cce34d0c4650c30e7edb1ced9"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/0f0b6232af56441d0a2dcb173cc4f8d8aab39014"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/57077eeb586c42f124bc09e018449362223067b3"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/6f5fb689fdf80bdd143f22a502f9eb1f3c85e286"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/9174992ee1045c9c96e53eecda64f49dd7e8fbba"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/f1b4df9c260c51726da2e86e19322825fddeefd0"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Awaiting Analysis",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-121"
              }
            ],
            "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
            "type": "Secondary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-11-05T22:06:35+00:00",
      "cve": "CVE-2026-64539",
      "id": "CVE-2026-64539",
      "initial_release_date": "2026-07-27T00:00:00+00:00",
      "product_status:known_affected": "158",
      "product_status:known_not_affected": "42",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: Bluetooth: eir: Fix stack OOB write when prepending the Flags AD",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-64539.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-64539",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "total"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-10-16T15:42:00.875042Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "problemTypes": [
              {
                "descriptions": [
                  {
                    "cweId": "CWE-121",
                    "description": "CWE-121 Stack-based Buffer Overflow",
                    "lang": "en",
                    "type": "CWE"
                  }
                ]
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-10-16T15:42:02.409Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "product": "Linux",
              "programFiles": [
                "net/bluetooth/eir.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "lessThan": "0f0b6232af56441d0a2dcb173cc4f8d8aab39014",
                  "status": "affected",
                  "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
                  "versionType": "git"
                },
                {
                  "lessThan": "9174992ee1045c9c96e53eecda64f49dd7e8fbba",
                  "status": "affected",
                  "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
                  "versionType": "git"
                },
                {
                  "lessThan": "09301f1fdf2aef8cce34d0c4650c30e7edb1ced9",
                  "status": "affected",
                  "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
                  "versionType": "git"
                },
                {
                  "lessThan": "f1b4df9c260c51726da2e86e19322825fddeefd0",
                  "status": "affected",
                  "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
                  "versionType": "git"
                },
                {
                  "lessThan": "57077eeb586c42f124bc09e018449362223067b3",
                  "status": "affected",
                  "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
                  "versionType": "git"
                },
                {
                  "lessThan": "6f5fb689fdf80bdd143f22a502f9eb1f3c85e286",
                  "status": "affected",
                  "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
                  "versionType": "git"
                }
              ]
            },
            {
              "defaultStatus": "affected",
              "product": "Linux",
              "programFiles": [
                "net/bluetooth/eir.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "status": "affected",
                  "version": "4.1"
                },
                {
                  "lessThan": "4.1",
                  "status": "unaffected",
                  "version": "0",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.1.*",
                  "status": "unaffected",
                  "version": "6.1.178",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.6.*",
                  "status": "unaffected",
                  "version": "6.6.160",
                  "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": "6.1.178",
                      "versionStartIncluding": "4.1",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.6.160",
                      "versionStartIncluding": "4.1",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.12.97",
                      "versionStartIncluding": "4.1",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.18.40",
                      "versionStartIncluding": "4.1",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "7.1.5",
                      "versionStartIncluding": "4.1",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "7.2",
                      "versionStartIncluding": "4.1",
                      "vulnerable": true
                    }
                  ],
                  "negate": false,
                  "operator": "OR"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: eir: Fix stack OOB write when prepending the Flags AD\n\neir_create_adv_data() builds the advertising data into a fixed-size\nbuffer (\"size\", 31 for the legacy path). It may prepend a 3-byte \"Flags\"\nAD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies\nthe per-instance data without checking that it still fits:\n\n\tmemcpy(ptr, adv-\u003eadv_data, adv-\u003eadv_data_len);\n\ntlv_data_max_len() only reserves those 3 bytes when the user-supplied\nflags carry a managed-flags bit, so an instance added with flags == 0 is\naccepted with adv_data_len up to the full buffer. At advertise time the\nflags are still prepended, and the memcpy() writes 3 + adv_data_len\nbytes into the size-byte buffer:\n\n  BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)\n  Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65\n  Workqueue: hci0 hci_cmd_sync_work\n   __asan_memcpy (mm/kasan/shadow.c:106)\n   eir_create_adv_data (net/bluetooth/eir.c:301)\n   hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)\n   hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)\n   hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)\n  This frame has 1 object:\n   [32, 64) \u0027cp\u0027\n\nThe \"Flags\" structure is added by the kernel, not requested by\nuserspace, so only prepend it when it fits together with the instance\nadvertising data; when there is no room for both, drop the flags rather\nthan the user-provided data.\n\nReachable by a local user with CAP_NET_ADMIN owning an LE-only\ncontroller on the legacy advertising path."
            }
          ],
          "metrics": [
            {
              "cvssV3_1": {
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "scenarios": [
                {
                  "lang": "en",
                  "value": "AV:L - The overflow is driven entirely by locally supplied advertising data written to an AF_BLUETOOTH HCI control socket (MGMT_OP_ADD_ADVERTISING / ADD_EXT_ADV_DATA / MESH_SEND); no remote or adjacent Bluetooth peer can influence the length or contents. Consistent with the same-class CVE-2026-53209 and CVE-2026-64126, this is a local-only trigger.\nAC:L - The attacker fully controls both preconditions \u2014 submit an instance with flags==0 and adv_data_len at the maximum, containing no EIR_FLAGS element \u2014 and the kernel then deterministically prepends the 3-byte Flags AD on any LE-only controller. No race, no memory-layout luck, no retry needed.\nPR:L - Reaching the mgmt handler requires HCI_SOCK_TRUSTED, granted by CAP_NET_ADMIN, which is a delegated capability routinely held by the Bluetooth stack daemon rather than full system root, and this CNA scores the identical CAP_NET_ADMIN-gated Bluetooth mgmt paths (CVE-2026-64126, CVE-2026-53209, CVE-2026-31511) as PR:L. Choosing the higher-severity option where the privilege boundary is arguable.\nUI:N - The attacker issues the mgmt commands itself and the overflow fires from hci_cmd_sync_work when the instance is scheduled for advertising. No victim action of any kind is involved.\nS:U - The corruption is confined to the kernel\u0027s own stack within the same security authority; there is no VM, IOMMU, or sandbox boundary crossed.\nC:H - On the extended-advertising path the inflated length (254 \u003e 251) makes struct_size() copy 3 bytes of adjacent kernel stack past the DEFINE_FLEX pdu into the HCI command skb, which is exposed via the HCI monitor channel and handed to the controller for broadcast, and the stack corruption is generally leverageable for further disclosure.\nI:H - This is an out-of-bounds write of fully attacker-controlled bytes (the tail of the user-supplied adv_data) past a local stack object, and it additionally leaves hdev-\u003eadv_data_len set to a value larger than the data actually stored. An attacker-controlled linear stack overflow is treated as high integrity impact.\nA:H - Overwriting bytes immediately past the stack object corrupts adjacent frame state and, with CONFIG_STACKPROTECTOR, will trip __stack_chk_fail leading to a kernel panic; the reported KASAN stack-out-of-bounds confirms real memory corruption in hci_cmd_sync_work."
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-10-21T12:43:26.591Z",
            "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "shortName": "Linux"
          },
          "references": [
            {
              "url": "https://git.kernel.org/stable/c/0f0b6232af56441d0a2dcb173cc4f8d8aab39014"
            },
            {
              "url": "https://git.kernel.org/stable/c/9174992ee1045c9c96e53eecda64f49dd7e8fbba"
            },
            {
              "url": "https://git.kernel.org/stable/c/09301f1fdf2aef8cce34d0c4650c30e7edb1ced9"
            },
            {
              "url": "https://git.kernel.org/stable/c/f1b4df9c260c51726da2e86e19322825fddeefd0"
            },
            {
              "url": "https://git.kernel.org/stable/c/57077eeb586c42f124bc09e018449362223067b3"
            },
            {
              "url": "https://git.kernel.org/stable/c/6f5fb689fdf80bdd143f22a502f9eb1f3c85e286"
            }
          ],
          "title": "Bluetooth: eir: Fix stack OOB write when prepending the Flags AD",
          "x_generator": {
            "engine": "bippy-1.2.0"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "assignerShortName": "Linux",
        "cveId": "CVE-2026-64539",
        "datePublished": "2026-07-27T20:10:33.363Z",
        "dateReserved": "2026-07-19T15:36:31.795Z",
        "dateUpdated": "2026-10-21T12:43:26.591Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

FKIE_CVE-2026-64539

Vulnerability from fkie_nvd - Published: 2026-07-27 21:17 - Updated: 2026-11-03 18:15

Severity

7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Summary

References

	URL	Tags
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/09301f1fdf2aef8cce34d0c4650c30e7edb1ced9
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/0f0b6232af56441d0a2dcb173cc4f8d8aab39014
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/57077eeb586c42f124bc09e018449362223067b3
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/6f5fb689fdf80bdd143f22a502f9eb1f3c85e286
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/9174992ee1045c9c96e53eecda64f49dd7e8fbba
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/f1b4df9c260c51726da2e86e19322825fddeefd0

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/bluetooth/eir.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "0f0b6232af56441d0a2dcb173cc4f8d8aab39014",
              "status": "affected",
              "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
              "versionType": "git"
            },
            {
              "lessThan": "9174992ee1045c9c96e53eecda64f49dd7e8fbba",
              "status": "affected",
              "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
              "versionType": "git"
            },
            {
              "lessThan": "09301f1fdf2aef8cce34d0c4650c30e7edb1ced9",
              "status": "affected",
              "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
              "versionType": "git"
            },
            {
              "lessThan": "f1b4df9c260c51726da2e86e19322825fddeefd0",
              "status": "affected",
              "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
              "versionType": "git"
            },
            {
              "lessThan": "57077eeb586c42f124bc09e018449362223067b3",
              "status": "affected",
              "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
              "versionType": "git"
            },
            {
              "lessThan": "6f5fb689fdf80bdd143f22a502f9eb1f3c85e286",
              "status": "affected",
              "version": "b44133ff03be30b55f23036e62f403a3f7784fce",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/bluetooth/eir.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.1"
            },
            {
              "lessThan": "4.1",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.178",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.160",
              "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\nBluetooth: eir: Fix stack OOB write when prepending the Flags AD\n\neir_create_adv_data() builds the advertising data into a fixed-size\nbuffer (\"size\", 31 for the legacy path). It may prepend a 3-byte \"Flags\"\nAD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies\nthe per-instance data without checking that it still fits:\n\n\tmemcpy(ptr, adv-\u003eadv_data, adv-\u003eadv_data_len);\n\ntlv_data_max_len() only reserves those 3 bytes when the user-supplied\nflags carry a managed-flags bit, so an instance added with flags == 0 is\naccepted with adv_data_len up to the full buffer. At advertise time the\nflags are still prepended, and the memcpy() writes 3 + adv_data_len\nbytes into the size-byte buffer:\n\n  BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)\n  Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65\n  Workqueue: hci0 hci_cmd_sync_work\n   __asan_memcpy (mm/kasan/shadow.c:106)\n   eir_create_adv_data (net/bluetooth/eir.c:301)\n   hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)\n   hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)\n   hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)\n  This frame has 1 object:\n   [32, 64) \u0027cp\u0027\n\nThe \"Flags\" structure is added by the kernel, not requested by\nuserspace, so only prepend it when it fits together with the instance\nadvertising data; when there is no room for both, drop the flags rather\nthan the user-provided data.\n\nReachable by a local user with CAP_NET_ADMIN owning an LE-only\ncontroller on the legacy advertising path."
    }
  ],
  "id": "CVE-2026-64539",
  "lastModified": "2026-11-03T18:15:39.353",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.9,
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-64539",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-10-16T15:42:00.875042Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-07-27T21:17:06.277",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/09301f1fdf2aef8cce34d0c4650c30e7edb1ced9"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/0f0b6232af56441d0a2dcb173cc4f8d8aab39014"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/57077eeb586c42f124bc09e018449362223067b3"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/6f5fb689fdf80bdd143f22a502f9eb1f3c85e286"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/9174992ee1045c9c96e53eecda64f49dd7e8fbba"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f1b4df9c260c51726da2e86e19322825fddeefd0"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-121"
        }
      ],
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "type": "Secondary"
    }
  ]
}

GHSA-RXG5-JR9R-8PC7

Vulnerability from github – Published: 2026-07-27 21:31 – Updated: 2026-10-21 15:40

Details

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

Bluetooth: eir: Fix stack OOB write when prepending the Flags AD

eir_create_adv_data() builds the advertising data into a fixed-size buffer ("size", 31 for the legacy path). It may prepend a 3-byte "Flags" AD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies the per-instance data without checking that it still fits:

memcpy(ptr, adv->adv_data, adv->adv_data_len);

tlv_data_max_len() only reserves those 3 bytes when the user-supplied flags carry a managed-flags bit, so an instance added with flags == 0 is accepted with adv_data_len up to the full buffer. At advertise time the flags are still prepended, and the memcpy() writes 3 + adv_data_len bytes into the size-byte buffer:

BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301) Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65 Workqueue: hci0 hci_cmd_sync_work __asan_memcpy (mm/kasan/shadow.c:106) eir_create_adv_data (net/bluetooth/eir.c:301) hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310) hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817) hci_cmd_sync_work (net/bluetooth/hci_sync.c:332) This frame has 1 object: [32, 64) 'cp'

The "Flags" structure is added by the kernel, not requested by userspace, so only prepend it when it fits together with the instance advertising data; when there is no room for both, drop the flags rather than the user-provided data.

Reachable by a local user with CAP_NET_ADMIN owning an LE-only controller on the legacy advertising path.

Severity

7.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-64539"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-121"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-27T21:17:06Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: eir: Fix stack OOB write when prepending the Flags AD\n\neir_create_adv_data() builds the advertising data into a fixed-size\nbuffer (\"size\", 31 for the legacy path). It may prepend a 3-byte \"Flags\"\nAD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies\nthe per-instance data without checking that it still fits:\n\n\tmemcpy(ptr, adv-\u003eadv_data, adv-\u003eadv_data_len);\n\ntlv_data_max_len() only reserves those 3 bytes when the user-supplied\nflags carry a managed-flags bit, so an instance added with flags == 0 is\naccepted with adv_data_len up to the full buffer. At advertise time the\nflags are still prepended, and the memcpy() writes 3 + adv_data_len\nbytes into the size-byte buffer:\n\n  BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)\n  Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65\n  Workqueue: hci0 hci_cmd_sync_work\n   __asan_memcpy (mm/kasan/shadow.c:106)\n   eir_create_adv_data (net/bluetooth/eir.c:301)\n   hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)\n   hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)\n   hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)\n  This frame has 1 object:\n   [32, 64) \u0027cp\u0027\n\nThe \"Flags\" structure is added by the kernel, not requested by\nuserspace, so only prepend it when it fits together with the instance\nadvertising data; when there is no room for both, drop the flags rather\nthan the user-provided data.\n\nReachable by a local user with CAP_NET_ADMIN owning an LE-only\ncontroller on the legacy advertising path.",
  "id": "GHSA-rxg5-jr9r-8pc7",
  "modified": "2026-10-21T15:40:46Z",
  "published": "2026-07-27T21:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64539"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/09301f1fdf2aef8cce34d0c4650c30e7edb1ced9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0f0b6232af56441d0a2dcb173cc4f8d8aab39014"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/57077eeb586c42f124bc09e018449362223067b3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6f5fb689fdf80bdd143f22a502f9eb1f3c85e286"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9174992ee1045c9c96e53eecda64f49dd7e8fbba"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f1b4df9c260c51726da2e86e19322825fddeefd0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

MSRC_CVE-2026-64539

Vulnerability from csaf_microsoft - Published: 2026-08-11 01:03 - Updated: 2026-11-07 01:49

Summary

Bluetooth: eir: Fix stack OOB write when prepending the Flags AD

Scope

1 vulnerability in this advisory, including CVE-2026-64539.

CVE-2026-64539

7.8 (High)


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

Fixed: 1 product Known affected: 5 products

https://learn.microsoft.com/en-us/azure/azure-linux/tutoria…

Open the full advisory

OESA-2026-3317 (CVE-2026-31462)

Vulnerability from osv_openeuler – Published: 2026-08-13 13:57 – Updated: 2026-08-13 13:57 – 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:

drm/amdgpu: prevent immediate PASID reuse case

PASID resue could cause interrupt issue when process immediately runs into hw state left by previous process exited with the same PASID, it's possible that page faults are still pending in the IH ring buffer when the process exits and frees up its PASID. To prevent the case, it uses idr cyclic allocator same as kernel pid's.

(cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)(CVE-2026-31462)

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

media: hackrf: fix to not free memory after the device is registered in hackrf_probe()

In hackrf driver, the following race condition occurs:

        CPU0                        CPU1
hackrf_probe()
  kzalloc(); // alloc hackrf_dev
  ....
  v4l2_device_register();
  ....
                        fd = sys_open(&quot;/path/to/dev&quot;); // open hackrf fd
                        ....
  v4l2_device_unregister();
  ....
  kfree(); // free hackrf_dev
  ....
                        sys_ioctl(fd, ...);
                          v4l2_ioctl();
                            video_is_registered() // UAF!!
                        ....
                        sys_close(fd);
                          v4l2_release() // UAF!!
                            hackrf_video_release()
                              kfree(); // DFB!!

When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked.

However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked.

Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet.

And since release() free memory too, race to use-after-free and double-free vuln occur.

To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.(CVE-2026-31576)

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

nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map

The DAT inode's btree node cache (i_assoc_inode) is initialized lazily during btree operations. However, nilfs_mdt_save_to_shadow_map() assumes i_assoc_inode is already initialized when copying dirty pages to the shadow map during GC.

If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before any btree operation has occurred on the DAT inode, i_assoc_inode is NULL leading to a general protection fault.

Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always initialized before any GC operation can use it.(CVE-2026-31577)

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

media: as102: fix to not free memory after the device is registered in as102_usb_probe()

In as102_usb driver, the following race condition occurs:

        CPU0                        CPU1
as102_usb_probe()
  kzalloc(); // alloc as102_dev_t
  ....
  usb_register_dev();
                        fd = sys_open(&quot;/path/to/dev&quot;); // open as102 fd
                        ....
  usb_deregister_dev();
  ....
  kfree(); // free as102_dev_t
  ....
                        sys_close(fd);
                          as102_release() // UAF!!
                            as102_usb_release()
                              kfree(); // DFB!!

When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked.

In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln.

The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release().

In other words, let release() perform the last kfree when the final open FD is closed.(CVE-2026-31578)

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

fs/ntfs3: validate rec->used in journal-replay file record check

check_file_record() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths:

DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next))

When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall.

This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay

Fix this up by bounding rec->used correctly.

This is much like commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") which checked different values in this same switch statement.(CVE-2026-31716)

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

PCI: Fix pci_slot_trylock() error handling

Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails.

Before a4e772898f8b, the code did:

if (!pci_dev_trylock(dev)) /* <- lock bridge device / goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); / <- unlock bridge device */ goto unlock; } }

After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug.

This yields one of two errors:

A warning that the lock is being unlocked when no one holds it.
An incorrect unlock of a lock that belongs to another thread.

Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path.

[Same patch later posted by Keith at https://patch.msgid.link/(CVE-2026-43211)

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

bpf: Free reuseport cBPF prog after RCU grace period.

Eulgyu Kim reported the splat below with a repro. [0]

The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group.

The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for "e"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free().

If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs.

Let's defer freeing the reuseport cBPF prog after one RCU grace period.

Note "e"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref().

[0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 </IRQ> <TASK> __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---(CVE-2026-52910)

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

nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers

Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized.

Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator.

Fix this by shifting the error handling responsibility to the callers.(CVE-2026-52989)

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

Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()

rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it.

The buggy scenario involves two paths, with each column showing the order within that path:

rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change().

If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback.

Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use.

KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().(CVE-2026-53256)

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

btrfs: only release the dirty pages io tree after successful writes

[WARNING] With extra warning on dirty extent buffers at umount (aka, the next patch in the series), test case generic/388 can trigger the following warning about dirty extent buffers at unmount time:

BTRFS critical (device dm-2 state E): emergency shutdown BTRFS error (device dm-2 state E): error while writing out transaction: -30 BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction. BTRFS error (device dm-2 state EA): Transaction 9 aborted (error -30) BTRFS: error (device dm-2 state EA) in cleanup_transaction:2068: errno=-30 Readonly filesystem BTRFS info (device dm-2 state EA): forced readonly BTRFS info (device dm-2 state EA): last unmount of filesystem 4fbf2e15-f941-49a0-bc7c-716315d2777c ------------[ cut here ]------------ WARNING: disk-io.c:3311 at invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs], CPU#8: umount/914368 CPU: 8 UID: 0 PID: 914368 Comm: umount Tainted: G OE 7.1.0-rc1-custom+ #372 PREEMPT(full) 2de38db8d1deae71fde295430a0ff3ab98ccf596 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs] Call Trace: <TASK> close_ctree+0x52e/0x574 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd] generic_shutdown_super+0x89/0x1a0 kill_anon_super+0x16/0x40 btrfs_kill_super+0x16/0x20 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd] deactivate_locked_super+0x2d/0xb0 cleanup_mnt+0xdc/0x140 task_work_run+0x5a/0xa0 exit_to_user_mode_loop+0x123/0x4b0 do_syscall_64+0x243/0x7c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- BTRFS warning (device dm-2 state EA): unable to release extent buffer 30539776 owner 9 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30621696 owner 257 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30638080 owner 258 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30654464 owner 7 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30703616 owner 2 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30720000 owner 10 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30736384 owner 4 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30752768 owner 11 gen 9 refs 2 flags 0x7

I'm using a stripped down version, which seems to trigger the warning more reliably:

_fsstress_pid="" workload() { dmesg -C mkfs.btrfs -f -K $dev > /dev/null echo 1 > /sys/kernel/debug/clear_warn_once mount $dev $mnt $fsstress -w -n 1024 -p 4 -d $mnt & _fsstress_pid=$! sleep 0 $godown $mnt pkill --echo -PIPE fsstress > /dev/null wait $_fsstress_pid unset _fsstress_pid umount $mnt

if dmesg | grep -q &quot;WARNING&quot;; then
    fail
fi

}

for (( i = 0; i < $runtime; i++ )); do echo "=== $i/$runtime ===" workload done

[CAUSE] Inside btrfs_write_and_wait_transaction(), we first try to write all dirty ebs, then wait for them to finish.

After that we call btrfs_extent_io_tree_release() to free all extent states from dirty_pages io tree.

However if we hit an error from btrfs_write_marked_extent(), then we still call btrfs_extent_io_tree_release() to clear that dirty_pages io tree, which may contain dirty records that we haven't yet submitted.

Furthermore, the later transaction cleanup path will utilize that dirty_pages io tree to properly cleanup those dirty ebs, but since it's already empty, no dirty ebs are properly cleaned up, thus will later trigger the warnings inside invalidate_btree_folios(). ---truncated---(CVE-2026-53284)

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

udf: reject descriptors with oversized CRC length

udf_read_tagged() skips CRC verification when descCRCLength + sizeof(struct tag) exceeds the block size. A crafted UDF image can set descCRCLength to an oversized value to bypass CRC validation entirely; the descriptor is then accepted based solely on the 8-bit tag checksum, which is trivially recomputable.

Reject such descriptors instead of silently accepting them. A legitimate single-block descriptor should never have a CRC length that exceeds the block.(CVE-2026-53369)

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

drm/amdgpu/vce: Prevent partial address patches

In the case that only one of lo/hi is valid, the patching could result in a bad address written to in FW.(CVE-2026-53375)

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

ksmbd: fix out-of-bounds read in smb_check_perm_dacl()

The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them.

CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read.

A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs.

Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().(CVE-2026-53390)

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

nfsd: release layout stid on setlease failure

nfs4_alloc_stid() publishes the new stid into cl->cl_stateids via idr_alloc_cyclic() under cl_lock before returning to nfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then fails, the error path frees the layout stateid directly with kmem_cache_free() without ever calling idr_remove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (states_show, client teardown) dereferences the dangling pointer.

The correct teardown for an IDR-published stid is nfs4_put_stid(), which removes the IDR slot under cl_lock, dispatches sc_free (nfsd4_free_layout_stateid) to release ls->ls_file via nfsd4_close_layout(), and drops the nfs4_file reference in its tail.

A second issue blocks that switch: nfsd4_free_layout_stateid() unconditionally inspects ls->ls_fence_work via delayed_work_pending() under ls_lock, but INIT_DELAYED_WORK(&ls->ls_fence_work, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayed_work.

nfsd4_alloc_layout_stateid()
  nfs4_alloc_stid()           /* idr_alloc_cyclic under cl_lock */
  nfsd4_layout_setlease()     /* fails */
    nfs4_put_stid()
      nfsd4_free_layout_stateid()
        delayed_work_pending(&amp;ls-&gt;ls_fence_work)  /* needs INIT */
        nfsd4_close_layout()  /* nfsd_file_put(ls-&gt;ls_file) */
      put_nfs4_file()

Fix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK initialization above the nfsd4_layout_setlease() call, and replace the manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup with a single nfs4_put_stid(stp).(CVE-2026-53399)

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

KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path

In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage):

__sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation.
The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition.

Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer.

Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region.

================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214

CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: <TASK> dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK>

The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected

Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint

sean: add sample KASAN splat, Fixes, and stable@

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

ocfs2: reject oversized group bitmap descriptors

ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap.

Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used.

Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)(CVE-2026-63796)

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

KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level

When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, before querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot.

When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage.

But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds.

BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: <TASK> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK>

Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.(CVE-2026-63807)

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

keys: Pin request_key_auth payload in instantiate paths

A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ =========================

create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF

helper completed detach and free rka destroy auth key wake up use rka->target_key USE-AFTER-FREE

Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy.

jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.

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

USB: serial: mct_u232: fix memory corruption with small endpoint

The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint.

Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.(CVE-2026-63898)

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

KVM: SEV: Ignore Port I/O requests of length '0'

Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.(CVE-2026-63940)

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

ixgbevf: fix use-after-free in VEPA multicast source pruning

ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor:

dev_kfree_skb_irq(skb);
continue;

The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing skb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context.

The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here.

I do not have ixgbevf hardware; the bug was found by static analysis (scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags):

BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90)

QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible.(CVE-2026-64113)

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

vsock/vmci: fix UAF when peer resets connection during handshake

vmci_transport_recv_connecting_server() returned err = 0 for a peer RST in its default switch arm:

err = pkt-&gt;type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;

That made vmci_transport_recv_listen() skip vsock_remove_pending(), leaving the pending socket on the listener's pending_links with sk_state = TCP_CLOSE while destroy: still dropped the explicit reference taken before schedule_delayed_work().

One second later vsock_pending_work() observed is_pending=true and performed full cleanup: vsock_remove_pending() then the two trailing sock_put(sk) calls -- the first reached refcount 0 and __sk_freed the socket, and the second wrote into the freed object:

BUG: KASAN: slab-use-after-free in refcount_warn_saturate Write of size 4 at addr ffff88800b1cac80 by task kworker Workqueue: events vsock_pending_work

Treat peer RST like any other unexpected packet type (err = -EINVAL). All destroy: arms now return err < 0, so vmci_transport_recv_listen() removes pending from pending_links synchronously and vsock_pending_work() takes the is_pending=false / !rejected branch, dropping only its own work reference. This also closes the multi-packet race Sashiko reported on v2: pending is removed from the list before any subsequent packet can find it.

The pre-existing sk_acceptq_removed() gap on the err < 0 path of vmci_transport_recv_listen() that Sashiko also noted is not introduced or changed by this patch.

Tested on lts-6.12.79 with KASAN: 52/100 unpatched -> 0/100 patched.(CVE-2026-64115)

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

Bluetooth: bnep: Fix UAF read of dev->name

bnep_add_connection() needs to keep holding the bnep_session_sem while reading dev->name (just like bnep_get_connlist() does); otherwise the bnep_session() thread can concurrently free the net_device, which can for example be triggered by a concurrent bnep_del_connection().

(This UAF is fairly uninteresting from a security perspective; calling bnep_add_connection() requires passing a capable(CAP_NET_ADMIN) check. It also requires completely tearing down a netdev during a fairly tight race window.)(CVE-2026-64178)

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

crypto: qat - protect service table iterations with service_lock

The service_table list is protected by service_lock when entries are added or removed (in adf_service_add() and adf_service_remove()), but several functions iterate over the list without holding this lock.

A concurrent adf_service_register() or adf_service_unregister() call could modify the list during traversal, leading to list corruption or a use-after-free.

Fix this by holding service_lock across all list_for_each_entry() iterations of service_table in adf_dev_init(), adf_dev_start(), adf_dev_stop(), adf_dev_shutdown(), adf_dev_restarting_notify(), adf_dev_restarted_notify(), and adf_error_notifier().

The lock ordering is safe: callers of the static helpers (adf_dev_up() and adf_dev_down()) acquire state_lock before service_lock, and no event_hld callback or service_lock holder ever acquires state_lock in the reverse order.(CVE-2026-64305)

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

nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page

nvmet_execute_disc_get_log_page() validates only the dword alignment of the host-supplied Log Page Offset (lpo). The 64-bit offset is then added to a small kzalloc'd buffer that holds the discovery log page and the result is passed straight to nvmet_copy_to_sgl(), which memcpy()s data_len bytes out to the host with no source-side bound check:

u64 offset      = nvmet_get_log_page_offset(req-&gt;cmd);  /* 64-bit host */
size_t data_len = nvmet_get_log_page_len(req-&gt;cmd);     /* 32-bit host */
...
if (offset &amp; 0x3) { ... }                               /* only check */
...
alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);
buffer = kzalloc(alloc_len, GFP_KERNEL);
...
status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);

The Discovery controller is unauthenticated -- nvmet_host_allowed() returns true unconditionally for the discovery subsystem -- so the call is reachable pre-authentication by any TCP/RDMA/FC peer that can reach the nvmet target. With a discovery log page of ~1 KiB, an attacker requesting up to 4 KiB starting at offset == alloc_len reads the next slab page out and gets its content returned over the fabric (an empirical run on a default nvmet-tcp loopback target leaked 81 canonical kernel pointers in one Get Log Page response). Pointing the offset at unmapped kernel memory faults the in-kernel memcpy and crashes (or panics, on panic_on_oops=1) the target host instead.

The attacker-controlled source-side offset pattern "nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique to nvmet_execute_disc_get_log_page in the entire nvmet codebase: every other Get Log Page handler in admin-cmd.c either ignores lpo (and silently starts every response at offset 0) or tracks a local destination offset with a fixed source pointer.

Validate the host-supplied offset against the log page size, cap the copy length to what is actually available, and zero-fill any remainder of the host transfer buffer. The zero-fill matches the existing short-response pattern in nvmet_execute_get_log_changed_ns() (admin-cmd.c) and prevents leaking transport SGL contents when the host asks for more bytes than the log page contains.(CVE-2026-64320)

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

udf: validate sparing table length as an entry count, not a byte count

udf_load_sparable_map() accepts a sparing table when

sizeof(*st) + le16_to_cpu(st-&gt;reallocationTableLen) &gt; sb-&gt;s_blocksize

is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements:

for (i = 0; i &lt; le16_to_cpu(st-&gt;reallocationTableLen); i++) {
    struct sparingEntry *entry = &amp;st-&gt;mapEntry[i];
    ... entry-&gt;origLocation ...
}

in udf_get_pblock_spar15() and udf_relocate_blocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(st) + N <= blocksize, yet the consumers index sizeof(st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block. On a crafted UDF image this is an out-of-bounds read in udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the same length to udf_update_tag(), whose crc_itu_t() reads far past the block, and its memmove() through st->mapEntry[] is an out-of-bounds write.

Validate reallocationTableLen as the entry count it is, with struct_size().(CVE-2026-64322)

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

proc: protect ptrace_may_access() with exec_update_lock (FD links)

proc_pid_get_link() and proc_pid_readlink() currently look up the task from the pid once, then do the ptrace access check on that task, then look up the task from the pid a second time to do the actual access. That's racy in several ways.

To fix it, pass the task to the ->proc_get_link() handler, and instead of proc_fd_access_allowed(), introduce a new helper call_proc_get_link() that looks up and locks the task, does the access check, and calls ->proc_get_link().(CVE-2026-64375)

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

smb: client: mask server-provided mode to 07777 in modefromsid

When modefromsid is active, parse_dacl() applies the server-provided sub_auth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path.(CVE-2026-64379)

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

smb: client: harden POSIX SID length parsing

posix_info_sid_size() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.(CVE-2026-64380)

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

fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns

In the analysis pass of $LogFile journal replay, log_replay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcns_follow=1 and an action log record with lcns_follow=2 produces a kernel slab out-of-bounds write at mount time:

BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount

Two attacker-controlled fields can drive j+i past the allocated page_lcns[] array:

dp->lcns_follow (capacity) can be smaller than lrh->lcns_follow.
lrh->target_vcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge size_t.

Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL.

This mirrors the bounds-check pattern added in commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") and commit 0ca0485e4b2e ("fs/ntfs3: validate rec->used in journal-replay file record check").(CVE-2026-64432)

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

nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path

In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock.

Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().(CVE-2026-64534)

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

Bluetooth: eir: Fix stack OOB write when prepending the Flags AD

memcpy(ptr, adv-&gt;adv_data, adv-&gt;adv_data_len);

Reachable by a local user with CAP_NET_ADMIN owning an LE-only controller on the legacy advertising path.(CVE-2026-64539)

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

Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()

l2cap_sock_new_connection_cb() returned l2cap_pi(sk)->chan after release_sock(parent). Once the parent lock is dropped the newly enqueued child socket sk is reachable via the accept queue, so another task can accept and free it before the callback dereferences sk, resulting in a use-after-free.

Rework the ->new_connection() op so the core, rather than the callback, owns the child channel's lifetime. The op now receives a pre-allocated new_chan and returns an errno instead of allocating and returning a channel. l2cap_new_connection() allocates the child channel and links it into the conn list via __l2cap_chan_add() before invoking the callback, so the conn-list reference keeps the channel alive once release_sock(parent) exposes the socket to other tasks.

Channel configuration that was duplicated in l2cap_sock_init() and the various new_connection callbacks is consolidated into l2cap_chan_set_defaults(), which now inherits from the parent channel when one is supplied.(CVE-2026-64557)

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-2026-31462	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31576	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31577	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31578	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31716	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43211	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-52910	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-52989	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53256	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53284	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53369	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53375	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53390	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53399	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63794	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63796	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63807	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63823	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63898	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63940	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64113	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64115	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64178	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64305	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64320	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64322	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64375	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64379	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64380	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64432	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64534	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64539	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64557	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-328.0.0.229.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-328.0.0.229.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-328.0.0.229.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\ndrm/amdgpu: prevent immediate PASID reuse case\n\nPASID resue could cause interrupt issue when process\nimmediately runs into hw state left by previous\nprocess exited with the same PASID, it\u0026apos;s possible that\npage faults are still pending in the IH ring buffer when\nthe process exits and frees up its PASID. To prevent the\ncase, it uses idr cyclic allocator same as kernel pid\u0026apos;s.\n\n(cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)(CVE-2026-31462)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: hackrf: fix to not free memory after the device is registered in hackrf_probe()\n\nIn hackrf driver, the following race condition occurs:\n```\n\t\tCPU0\t\t\t\t\t\tCPU1\nhackrf_probe()\n  kzalloc(); // alloc hackrf_dev\n  ....\n  v4l2_device_register();\n  ....\n\t\t\t\t\t\tfd = sys_open(\u0026quot;/path/to/dev\u0026quot;); // open hackrf fd\n\t\t\t\t\t\t....\n  v4l2_device_unregister();\n  ....\n  kfree(); // free hackrf_dev\n  ....\n\t\t\t\t\t\tsys_ioctl(fd, ...);\n\t\t\t\t\t\t  v4l2_ioctl();\n\t\t\t\t\t\t    video_is_registered() // UAF!!\n\t\t\t\t\t\t....\n\t\t\t\t\t\tsys_close(fd);\n\t\t\t\t\t\t  v4l2_release() // UAF!!\n\t\t\t\t\t\t    hackrf_video_release()\n\t\t\t\t\t\t      kfree(); // DFB!!\n```\n\nWhen a V4L2 or video device is unregistered, the device node is removed so\nnew open() calls are blocked.\n\nHowever, file descriptors that are already open-and any in-flight I/O-do\nnot terminate immediately; they remain valid until the last reference is\ndropped and the driver\u0026apos;s release() is invoked.\n\nTherefore, freeing device memory on the error path after hackrf_probe()\nhas registered dev it will lead to a race to use-after-free vuln, since\nthose already-open handles haven\u0026apos;t been released yet.\n\nAnd since release() free memory too, race to use-after-free and\ndouble-free vuln occur.\n\nTo prevent this, if device is registered from probe(), it should be\nmodified to free memory only through release() rather than calling\nkfree() directly.(CVE-2026-31576)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map\n\nThe DAT inode\u0026apos;s btree node cache (i_assoc_inode) is initialized lazily\nduring btree operations. However, nilfs_mdt_save_to_shadow_map()\nassumes i_assoc_inode is already initialized when copying dirty pages\nto the shadow map during GC.\n\nIf NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before\nany btree operation has occurred on the DAT inode, i_assoc_inode is\nNULL leading to a general protection fault.\n\nFix this by calling nilfs_attach_btree_node_cache() on the DAT inode\nin nilfs_dat_read() at mount time, ensuring i_assoc_inode is always\ninitialized before any GC operation can use it.(CVE-2026-31577)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: as102: fix to not free memory after the device is registered in as102_usb_probe()\n\nIn as102_usb driver, the following race condition occurs:\n```\n\t\tCPU0\t\t\t\t\t\tCPU1\nas102_usb_probe()\n  kzalloc(); // alloc as102_dev_t\n  ....\n  usb_register_dev();\n\t\t\t\t\t\tfd = sys_open(\u0026quot;/path/to/dev\u0026quot;); // open as102 fd\n\t\t\t\t\t\t....\n  usb_deregister_dev();\n  ....\n  kfree(); // free as102_dev_t\n  ....\n\t\t\t\t\t\tsys_close(fd);\n\t\t\t\t\t\t  as102_release() // UAF!!\n\t\t\t\t\t\t    as102_usb_release()\n\t\t\t\t\t\t      kfree(); // DFB!!\n```\n\nWhen a USB character device registered with usb_register_dev() is later\nunregistered (via usb_deregister_dev() or disconnect), the device node is\nremoved so new open() calls fail. However, file descriptors that are\nalready open do not go away immediately: they remain valid until the last\nreference is dropped and the driver\u0026apos;s .release() is invoked.\n\nIn as102, as102_usb_probe() calls usb_register_dev() and then, on an\nerror path, does usb_deregister_dev() and frees as102_dev_t right away.\nIf userspace raced a successful open() before the deregistration, that\nopen FD will later hit as102_release() --\u0026gt; as102_usb_release() and access\nor free as102_dev_t again, occur a race to use-after-free and\ndouble-free vuln.\n\nThe fix is to never kfree(as102_dev_t) directly once usb_register_dev()\nhas succeeded. After deregistration, defer freeing memory to .release().\n\nIn other words, let release() perform the last kfree when the final open\nFD is closed.(CVE-2026-31578)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: validate rec-\u0026gt;used in journal-replay file record check\n\ncheck_file_record() validates rec-\u0026gt;total against the record size but\nnever validates rec-\u0026gt;used.  The do_action() journal-replay handlers read\nrec-\u0026gt;used from disk and use it to compute memmove lengths:\n\n  DeleteAttribute:    memmove(attr, ..., used - asize - roff)\n  CreateAttribute:    memmove(..., attr, used - roff)\n  change_attr_size:   memmove(..., used - PtrOffset(rec, next))\n\nWhen rec-\u0026gt;used is smaller than the offset of a validated attribute, or\nlarger than the record size, these subtractions can underflow allowing\nus to copy huge amounts of memory in to a 4kb buffer, generally\nconsidered a bad idea overall.\n\nThis requires a corrupted filesystem, which isn\u0026apos;t a threat model the\nkernel really needs to worry about, but checking for such an obvious\nout-of-bounds value is good to keep things robust, especially on journal\nreplay\n\nFix this up by bounding rec-\u0026gt;used correctly.\n\nThis is much like commit b2bc7c44ed17 (\u0026quot;fs/ntfs3: Fix slab-out-of-bounds\nread in DeleteIndexEntryRoot\u0026quot;) which checked different values in this\nsame switch statement.(CVE-2026-31716)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix pci_slot_trylock() error handling\n\nCommit a4e772898f8b (\u0026quot;PCI: Add missing bridge lock to pci_bus_lock()\u0026quot;)\ndelegates the bridge device\u0026apos;s pci_dev_trylock() to pci_bus_trylock() in\npci_slot_trylock(), but it forgets to remove the corresponding\npci_dev_unlock() when pci_bus_trylock() fails.\n\nBefore a4e772898f8b, the code did:\n\n  if (!pci_dev_trylock(dev)) /* \u0026lt;- lock bridge device */\n    goto unlock;\n  if (dev-\u0026gt;subordinate) {\n    if (!pci_bus_trylock(dev-\u0026gt;subordinate)) {\n      pci_dev_unlock(dev);   /* \u0026lt;- unlock bridge device */\n      goto unlock;\n    }\n  }\n\nAfter a4e772898f8b the bridge-device lock is no longer taken, but the\npci_dev_unlock(dev) on the failure path was left in place, leading to the\nbug.\n\nThis yields one of two errors:\n\n  1. A warning that the lock is being unlocked when no one holds it.\n  2. An incorrect unlock of a lock that belongs to another thread.\n\nFix it by removing the now-redundant pci_dev_unlock(dev) on the failure\npath.\n\n[Same patch later posted by Keith at\nhttps://patch.msgid.link/(CVE-2026-43211)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Free reuseport cBPF prog after RCU grace period.\n\nEulgyu Kim reported the splat below with a repro. [0]\n\nThe repro sets up a UDP reuseport group with a cBPF prog and\nreplaces it with a new one while another thread is sending\na UDP packet to the group.\n\nThe reuseport prog is freed by sk_reuseport_prog_free().\nbpf_prog_put() is called for \u0026quot;e\u0026quot;BPF prog to destruct through\nmultiple stages while cBPF prog is freed immediately by\nbpf_release_orig_filter() and bpf_prog_free().\n\nIf a reuseport prog is detached from the setsockopt() path\n(reuseport_attach_prog() or reuseport_detach_prog()),\nsk_reuseport_prog_free() is called without waiting for RCU\nreaders to complete, resulting in various bugs.\n\nLet\u0026apos;s defer freeing the reuseport cBPF prog after one RCU\ngrace period.\n\nNote \u0026quot;e\u0026quot;BPF prog is safe as is unless the fast path starts\nto touch fields destroyed in bpf_prog_put_deferred() and\n__bpf_prog_put_noref().\n\n[0]:\nBUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596\nRead of size 4 at addr ffffc9000051e004 by task slowme/10208\nCPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full)\nHardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596\n udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495\n __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723\n __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752\n __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752\n ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207\n ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241\n NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318\n NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318\n __netif_receive_skb_one_core net/core/dev.c:6181 [inline]\n __netif_receive_skb net/core/dev.c:6294 [inline]\n process_backlog+0xaa4/0x1960 net/core/dev.c:6645\n __napi_poll+0xae/0x340 net/core/dev.c:7709\n napi_poll net/core/dev.c:7772 [inline]\n net_rx_action+0x5d7/0xf50 net/core/dev.c:7929\n handle_softirqs+0x22b/0x870 kernel/softirq.c:622\n do_softirq+0x76/0xd0 kernel/softirq.c:523\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450\n local_bh_enable include/linux/bottom_half.h:33 [inline]\n rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline]\n __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890\n neigh_output include/net/neighbour.h:556 [inline]\n ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237\n NF_HOOK_COND include/linux/netfilter.h:307 [inline]\n ip_output+0x29f/0x450 net/ipv4/ip_output.c:438\n ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508\n udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195\n udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg net/socket.c:742 [inline]\n __sys_sendto+0x554/0x680 net/socket.c:2206\n __do_sys_sendto net/socket.c:2213 [inline]\n __se_sys_sendto net/socket.c:2209 [inline]\n __x64_sys_sendto+0xde/0x100 net/socket.c:2209\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x415a2d\nCode: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d\nRDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003\nRBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010\nR10: 0000000000000000 R11: \n---truncated---(CVE-2026-52910)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers\n\nCurrently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds\nPDU length or offset, it triggers nvmet_tcp_fatal_error(cmd-\u0026gt;queue)\nand returns early. However, because the function returns void, the\ncallers are entirely unaware that a fatal error has occurred and\nthat the cmd-\u0026gt;recv_msg.msg_iter was left uninitialized.\n\nCallers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly\noverwrite the queue state with queue-\u0026gt;rcv_state = NVMET_TCP_RECV_DATA\nConsequently, the socket receiving loop may attempt to read incoming\nnetwork data into the uninitialized iterator.\n\nFix this by shifting the error handling responsibility to the callers.(CVE-2026-52989)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()\n\nrfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock,\nbut returns the selected listener after dropping that lock without\ntaking a reference. rfcomm_connect_ind() then locks the listener,\nqueues a child socket on it, and may notify it after unlocking it.\n\nThe buggy scenario involves two paths, with each column showing the\norder within that path:\n\nrfcomm_connect_ind():            listener close:\n  1. Find parent in              1. close() enters\n     rfcomm_get_sock_by_channel()   rfcomm_sock_release().\n  2. Drop rfcomm_sk_list.lock    2. rfcomm_sock_shutdown()\n     without pinning parent.        closes the listener.\n  3. Call lock_sock(parent) and  3. rfcomm_sock_kill()\n     bt_accept_enqueue(parent,      unlinks and puts parent.\n     sk, true).\n  4. Read parent flags and may   4. parent can be freed.\n     call sk_state_change().\n\nIf close wins the race, parent can be freed before\nrfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the\ndeferred-setup callback.\n\nTake a reference on the listener before leaving rfcomm_sk_list.lock.\nAfter lock_sock() succeeds, recheck that it is still in BT_LISTEN\nbefore queueing a child, cache the deferred-setup bit while the parent\nis locked, and drop the reference after the last parent use.\n\nKASAN reported a slab-use-after-free in lock_sock_nested() from\nrfcomm_connect_ind(), with the freeing stack going through\nrfcomm_sock_kill() and rfcomm_sock_release().(CVE-2026-53256)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: only release the dirty pages io tree after successful writes\n\n[WARNING]\nWith extra warning on dirty extent buffers at umount (aka, the next\npatch in the series), test case generic/388 can trigger the following\nwarning about dirty extent buffers at unmount time:\n\n  BTRFS critical (device dm-2 state E): emergency shutdown\n  BTRFS error (device dm-2 state E): error while writing out transaction: -30\n  BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction.\n  BTRFS error (device dm-2 state EA): Transaction 9 aborted (error -30)\n  BTRFS: error (device dm-2 state EA) in cleanup_transaction:2068: errno=-30 Readonly filesystem\n  BTRFS info (device dm-2 state EA): forced readonly\n  BTRFS info (device dm-2 state EA): last unmount of filesystem 4fbf2e15-f941-49a0-bc7c-716315d2777c\n  ------------[ cut here ]------------\n  WARNING: disk-io.c:3311 at invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs], CPU#8: umount/914368\n  CPU: 8 UID: 0 PID: 914368 Comm: umount Tainted: G           OE       7.1.0-rc1-custom+ #372 PREEMPT(full)  2de38db8d1deae71fde295430a0ff3ab98ccf596\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022\n  RIP: 0010:invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   close_ctree+0x52e/0x574 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]\n   generic_shutdown_super+0x89/0x1a0\n   kill_anon_super+0x16/0x40\n   btrfs_kill_super+0x16/0x20 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]\n   deactivate_locked_super+0x2d/0xb0\n   cleanup_mnt+0xdc/0x140\n   task_work_run+0x5a/0xa0\n   exit_to_user_mode_loop+0x123/0x4b0\n   do_syscall_64+0x243/0x7c0\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n   \u0026lt;/TASK\u0026gt;\n  ---[ end trace 0000000000000000 ]---\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30539776 owner 9 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30621696 owner 257 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30638080 owner 258 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30654464 owner 7 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30703616 owner 2 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30720000 owner 10 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30736384 owner 4 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30752768 owner 11 gen 9 refs 2 flags 0x7\n\nI\u0026apos;m using a stripped down version, which seems to trigger the warning\nmore reliably:\n\n  _fsstress_pid=\u0026quot;\u0026quot;\n  workload()\n  {\n  \tdmesg -C\n  \tmkfs.btrfs -f -K $dev \u0026gt; /dev/null\n  \techo 1 \u0026gt; /sys/kernel/debug/clear_warn_once\n  \tmount $dev $mnt\n  \t$fsstress -w -n 1024 -p 4 -d $mnt \u0026amp;\n  \t_fsstress_pid=$!\n  \tsleep 0\n  \t$godown $mnt\n  \tpkill --echo -PIPE fsstress \u0026gt; /dev/null\n  \twait $_fsstress_pid\n  \tunset _fsstress_pid\n  \tumount $mnt\n\n  \tif dmesg | grep -q \u0026quot;WARNING\u0026quot;; then\n  \t\tfail\n  \tfi\n  }\n\n  for (( i = 0; i \u0026lt; $runtime; i++ )); do\n  \techo \u0026quot;=== $i/$runtime ===\u0026quot;\n  \tworkload\n  done\n\n[CAUSE]\nInside btrfs_write_and_wait_transaction(), we first try to write all\ndirty ebs, then wait for them to finish.\n\nAfter that we call btrfs_extent_io_tree_release() to free all\nextent states from dirty_pages io tree.\n\nHowever if we hit an error from btrfs_write_marked_extent(), then we\nstill call btrfs_extent_io_tree_release() to clear that dirty_pages io\ntree, which may contain dirty records that we haven\u0026apos;t yet submitted.\n\nFurthermore, the later transaction cleanup path will utilize that\ndirty_pages io tree to properly cleanup those dirty ebs, but since it\u0026apos;s\nalready empty, no dirty ebs are properly cleaned up, thus will later\ntrigger the warnings inside invalidate_btree_folios().\n---truncated---(CVE-2026-53284)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: reject descriptors with oversized CRC length\n\nudf_read_tagged() skips CRC verification when descCRCLength +\nsizeof(struct tag) exceeds the block size.  A crafted UDF image can\nset descCRCLength to an oversized value to bypass CRC validation\nentirely; the descriptor is then accepted based solely on the 8-bit\ntag checksum, which is trivially recomputable.\n\nReject such descriptors instead of silently accepting them.  A\nlegitimate single-block descriptor should never have a CRC length that\nexceeds the block.(CVE-2026-53369)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/vce: Prevent partial address patches\n\nIn the case that only one of lo/hi is valid, the patching could result\nin a bad address written to in FW.(CVE-2026-53375)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix out-of-bounds read in smb_check_perm_dacl()\n\nThe permission-check ACE walk in smb_check_perm_dacl() validates the ACE\nheader size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it\nnever checks that ace-\u0026gt;size is actually large enough to contain\nnum_subauth sub-authorities before compare_sids() dereferences them.\n\nCIFS_SID_BASE_SIZE covers the SID header up to but excluding the\nsub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header,\nso the existing guards only guarantee the 8-byte SID base, i.e. zero\nsub-authorities. compare_sids() then reads ace-\u0026gt;sid.sub_auth[i] for\ni \u0026lt; min(local_sid-\u0026gt;num_subauth, ace-\u0026gt;sid.num_subauth). The local\ncomparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid()\nresult) always have at least one sub-authority, and an attacker controls\nthe ACE revision and authority bytes (which lie within the in-bounds SID\nbase), so they can match one of those SIDs and force the sub_auth read.\n\nA crafted ACE with size == 16 and num_subauth \u0026gt;= 1 placed at the tail of\nthe security descriptor therefore causes a heap out-of-bounds read of up\nto SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd\nallocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr()\ninto a buffer sized exactly to the on-disk data (kzalloc(sd_size) in\nndr_decode_v4_ntacl()), so the read lands past the allocation. The\nmalformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL\nis not normalised before being written to the security.NTACL xattr) and\nthe read fires on a subsequent SMB2_CREATE access check, making this\nreachable by an authenticated client on a share that uses ACL xattrs.\n\nAdd the missing num_subauth-versus-ace_size check, mirroring the\nidentical guards already present in the sibling parsers parse_dacl() and\nsmb_inherit_dacl().(CVE-2026-53390)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: release layout stid on setlease failure\n\nnfs4_alloc_stid() publishes the new stid into cl-\u0026gt;cl_stateids via\nidr_alloc_cyclic() under cl_lock before returning to\nnfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then\nfails, the error path frees the layout stateid directly with\nkmem_cache_free() without ever calling idr_remove(), leaving the\nIDR slot pointing at freed slab memory. Any subsequent IDR walker\n(states_show, client teardown) dereferences the dangling pointer.\n\nThe correct teardown for an IDR-published stid is nfs4_put_stid(),\nwhich removes the IDR slot under cl_lock, dispatches sc_free\n(nfsd4_free_layout_stateid) to release ls-\u0026gt;ls_file via\nnfsd4_close_layout(), and drops the nfs4_file reference in its\ntail.\n\nA second issue blocks that switch: nfsd4_free_layout_stateid()\nunconditionally inspects ls-\u0026gt;ls_fence_work via\ndelayed_work_pending() under ls_lock, but\nINIT_DELAYED_WORK(\u0026amp;ls-\u0026gt;ls_fence_work, ...) currently runs only\nafter the setlease call. On the setlease-failure path the\ndestructor would touch an uninitialized delayed_work.\n\n    nfsd4_alloc_layout_stateid()\n      nfs4_alloc_stid()           /* idr_alloc_cyclic under cl_lock */\n      nfsd4_layout_setlease()     /* fails */\n        nfs4_put_stid()\n          nfsd4_free_layout_stateid()\n            delayed_work_pending(\u0026amp;ls-\u0026gt;ls_fence_work)  /* needs INIT */\n            nfsd4_close_layout()  /* nfsd_file_put(ls-\u0026gt;ls_file) */\n          put_nfs4_file()\n\nFix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK\ninitialization above the nfsd4_layout_setlease() call, and replace\nthe manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup\nwith a single nfs4_put_stid(stp).(CVE-2026-53399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path\n\nIn sev_dbg_crypt(), the per-iteration transfer length is bounded by\nthe source page offset (PAGE_SIZE - s_off) but not by the destination\npage offset (PAGE_SIZE - d_off).  When d_off \u0026gt; s_off, the encrypt\npath (__sev_dbg_encrypt_user) performs a read-modify-write using a\nsingle-page intermediate buffer (dst_tpage):\n\n  1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off \u0026amp; 15), 16)\n     before issuing the PSP command.  If len + (d_off \u0026amp; 15) \u0026gt; PAGE_SIZE,\n     the PSP writes beyond the end of the 4096-byte dst_tpage allocation.\n\n  2. The subsequent memcpy()/copy_from_user() into\n     page_address(dst_tpage) + (d_off \u0026amp; 15) of \u0026apos;len\u0026apos; bytes overflows\n     by up to 15 bytes under the same condition.\n\nTrigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE -\nthe PSP is instructed to write round_up(4097, 16) = 4112 bytes to\na 4096-byte buffer.\n\nFix by also bounding len by (PAGE_SIZE - d_off), the same check that\nsev_send_update_data() already performs for its single-page guest\nregion.\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd]\n Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214\n\n CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G     U  W           7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY\n Tainted: [U]=USER, [W]=WARN\n Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  dump_stack_lvl+0x54/0x70\n  print_report+0xbc/0x260\n  kasan_report+0xa2/0xd0\n  kasan_check_range+0x25f/0x2c0\n  __asan_memcpy+0x40/0x70\n  sev_dbg_crypt+0x993/0xd10 [kvm_amd]\n  sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd]\n  kvm_vm_ioctl+0x65d/0x6d0 [kvm]\n  __se_sys_ioctl+0xb2/0x100\n  do_syscall_64+0xe8/0x870\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n  \u0026lt;/TASK\u0026gt;\n\n The buggy address belongs to the physical page:\n page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb\n memcg:ff11000112827d82\n flags: 0x1400000000000000(node=1|zone=1)\n raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000\n raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n  ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u0026gt;ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n                    ^\n  ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n  ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ==================================================================\n Disabling lock debugging due to kernel taint\n\n[sean: add sample KASAN splat, Fixes, and stable@](CVE-2026-63794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: reject oversized group bitmap descriptors\n\nocfs2_validate_gd_parent() only bounds bg_bits against the parent\nallocator\u0026apos;s chain geometry.  A malicious descriptor can still claim a\nbg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in\nthe group descriptor block, so later bitmap scans and bit updates can run\npast bg_bitmap.\n\nAdd a physical-cap check based on ocfs2_group_bitmap_size() for the parent\nallocator type and reject descriptors whose bg_size or bg_bits exceed that\ncapacity.  Keep the existing chain geometry check so both the on-disk\nbitmap layout and the allocator metadata must agree before the descriptor\nis used.\n\nValidation reproduced this kernel report:\nKASAN use-after-free in _find_next_bit+0x7f/0xc0\nRead of size 8\nCall trace:\n  dump_stack_lvl+0x66/0xa0 (?:?)\n  print_report+0xd0/0x630 (?:?)\n  _find_next_bit+0x7f/0xc0 (?:?)\n  srso_alias_return_thunk+0x5/0xfbef5 (?:?)\n  __virt_addr_valid+0x188/0x2f0 (?:?)\n  kasan_report+0xe4/0x120 (?:?)\n  ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375)\n  ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457)\n  ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86)\n  ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786)\n  ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886)\n  get_page_from_freelist+0x70e/0x2370 (?:?)\n  lock_release+0xc6/0x290 (?:?)\n  do_raw_spin_unlock+0x9a/0x100 (?:?)\n  kasan_unpoison+0x27/0x60 (?:?)\n  __bfs+0x147/0x240 (?:?)\n  get_page_from_freelist+0x83d/0x2370 (?:?)\n  ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96)\n  sched_domains_numa_masks_clear+0x70/0xd0 (?:?)\n  check_irq_usage+0xe8/0xb70 (?:?)\n  __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497)\n  check_path+0x24/0x50 (?:?)\n  rcu_is_watching+0x20/0x50 (?:?)\n  check_prev_add+0xfd/0xd00 (?:?)\n  ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?)\n  __folio_batch_add_and_move+0x1f5/0x3d0 (?:?)\n  ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?)\n  filemap_add_folio+0x105/0x1f0 (?:?)\n  ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043)\n  ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?)\n  down_write+0xf5/0x180 (?:?)\n  ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?)\n  __mark_inode_dirty+0x758/0x9a0 (?:?)\n  inode_to_bdi+0x41/0x90 (?:?)\n  balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?)\n  generic_perform_write+0x252/0x440 (?:?)\n  mnt_put_write_access_file+0x16/0x70 (?:?)\n  file_update_time_flags+0xe4/0x200 (?:?)\n  ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?)\n  lock_acquire+0x184/0x2f0 (?:?)\n  ksys_write+0xd2/0x170 (?:?)\n  apparmor_file_permission+0xf5/0x310 (?:?)\n  read_zero+0x8d/0x140 (?:?)\n  lock_is_held_type+0x8f/0x100 (?:?)(CVE-2026-63796)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level\n\nWhen recovering hugepages in the shadow MMU, verify that the base gfn of\nthe shadow page is actually contained within the target memslot, *before*\nquerying the max mapping level given the shadow page\u0026apos;s gfn.  Failure to\npre-check the validity of the gfn can lead to an out-of-bounds access to\nthe slot\u0026apos;s lpage_info (which typically manifests as a host #PF because the\nlpage_info is vmalloc\u0026apos;d) if the guest creates a hugepage mapping (in its\nPTEs) that extends \u0026quot;below\u0026quot; the bounds of a memslot.\n\nWhen faulting in memory for a guest, and the size of the guest mapping is\ngreater than KVM\u0026apos;s (current) max mapping, then KVM will create a \u0026quot;direct\u0026quot;\nshadow page (direct in that there are no gPTEs to shadow, and so the target\ngfn is a direct calculation given the base gfn of the shadow page).  The\nhugepage recovery flow looks for such direct shadow pages, as forcing 4KiB\nmappings when dirty logging generates the guest \u0026gt; host mapping size case.\nWhen the 4KiB restriction is lifted, then KVM can replace the shadow page\nwith a hugepage.\n\nBut if KVM originally used a smaller mapping than the guest because the\nrange of memory covered by the guest hugepage exceeds the bounds of a\nmemslot, then KVM will link a direct shadow page with a gfn that is outside\nthe bounds of the memslot being used to fault in memory.  The rmap entry\nadded for the leaf mapping is correct and within bounds, but the gfn of the\nleaf SPTE\u0026apos;s parent shadow page will be out of bounds.\n\n  BUG: unable to handle page fault for address: ffffc90000806ffc\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0\n  Oops: Oops: 0000 [#1] SMP\n  CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm]\n   kvm_set_memslot+0x1ee/0x590 [kvm]\n   kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm]\n   kvm_vm_ioctl+0x9bf/0x15d0 [kvm]\n   __x64_sys_ioctl+0x8a/0xd0\n   do_syscall_64+0xb7/0xbb0\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n  RIP: 0033:0x7f21c0f1a9bf\n   \u0026lt;/TASK\u0026gt;\n\nDon\u0026apos;t bother pre-checking the bounds of the potential hugepage, i.e. don\u0026apos;t\ncheck that e.g. sp-\u0026gt;gfn + KVM_PAGES_PER_HPAGE(sp-\u0026gt;role.level + 1) is also\nwithin the memslot, as the checks performed by kvm_mmu_max_mapping_level()\nare a superset of the basic bounds checks.  I.e. pre-checking the full\nrange would be a dubious micro-optimization.(CVE-2026-63807)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkeys: Pin request_key_auth payload in instantiate paths\n\nA: request_key()       B: KEYCTL_INSTANTIATE_IOV\n================       =========================\n\ncreate auth key\nstore rka in auth key\nwait for helper\n                       get auth key\n                       load rka from auth key\n                       copy user payload\n                       sleep on #PF\n\nhelper completed\ndetach and free rka\ndestroy auth key\n                       wake up\n                       use rka-\u0026gt;target_key\n                       **USE-AFTER-FREE**\n\nGive request_key_auth payloads a refcount.  Take a payload reference while\nauthkey-\u0026gt;sem stabilizes the payload and revocation state.  Hold that\nreference across the instantiate and reject paths.  Drop the auth key\nowning reference from revoke and destroy.\n\n[jarkko: Replaced the first two paragraphs of text with an actual\n concurrency scenario.](CVE-2026-63823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: mct_u232: fix memory corruption with small endpoint\n\nThe driver overrides the maximum transfer size for a specific device\nwhich only accepts 16 byte packets for its 32 byte bulk-out endpoint.\n\nMake sure to never increase the maximum transfer size to prevent slab\ncorruption should a malicious device report a smaller endpoint max\npacket size than expected.(CVE-2026-63898)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SEV: Ignore Port I/O requests of length \u0026apos;0\u0026apos;\n\nExplicitly ignore Port I/O requests of length \u0026apos;0\u0026apos; (or count \u0026apos;0\u0026apos;), so that\nsetting up the software scratch area (and other code) doesn\u0026apos;t have to\nworry about underflowing the length, and to allow for WARNing on trying\nto configure the scratch area with len==0.(CVE-2026-63940)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nixgbevf: fix use-after-free in VEPA multicast source pruning\n\nixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF\u0026apos;s\nown address (VEPA multicast workaround) by freeing the skb and\ncontinuing to the next descriptor:\n\n    dev_kfree_skb_irq(skb);\n    continue;\n\nThe skb pointer is declared outside the while loop and persists across\niterations.  Because the continue skips the \u0026quot;skb = NULL\u0026quot; reset at the\nbottom of the loop, the next iteration enters the \u0026quot;else if (skb)\u0026quot; path\nand calls ixgbevf_add_rx_frag() on the freed skb, dereferencing\nskb_shinfo(skb)-\u0026gt;nr_frags - a use-after-free in NAPI softirq context.\n\nThe sibling driver iavf already handles this correctly by nulling the\npointer before continuing.  Apply the same pattern here.\n\nI do not have ixgbevf hardware; the bug was found by static analysis\n(scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool\ncorroboration with the highest score in the scan).  The UAF was confirmed\nunder KASAN by loading a test module that reproduces the exact code\npattern (alloc skb, kfree_skb, then read skb_shinfo(skb)-\u0026gt;nr_frags):\n\n  BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000\n  Read of size 8 at addr 000000006163ae78 by task insmod/30\n  freed 208-byte region [000000006163adc0, 000000006163ae90)\n\nQEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF\ndriver does not include the VEPA source pruning path, so a full\nend-to-end reproduction with emulated hardware was not possible.(CVE-2026-64113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/vmci: fix UAF when peer resets connection during handshake\n\nvmci_transport_recv_connecting_server() returned err = 0 for a peer\nRST in its default switch arm:\n\n\terr = pkt-\u0026gt;type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;\n\nThat made vmci_transport_recv_listen() skip vsock_remove_pending(),\nleaving the pending socket on the listener\u0026apos;s pending_links with\nsk_state = TCP_CLOSE while destroy: still dropped the explicit\nreference taken before schedule_delayed_work().\n\nOne second later vsock_pending_work() observed is_pending=true and\nperformed full cleanup: vsock_remove_pending() then the two trailing\nsock_put(sk) calls -- the first reached refcount 0 and __sk_freed\nthe socket, and the second wrote into the freed object:\n\n  BUG: KASAN: slab-use-after-free in refcount_warn_saturate\n  Write of size 4 at addr ffff88800b1cac80 by task kworker\n  Workqueue: events vsock_pending_work\n\nTreat peer RST like any other unexpected packet type (err = -EINVAL).\nAll destroy: arms now return err \u0026lt; 0, so vmci_transport_recv_listen()\nremoves pending from pending_links synchronously and\nvsock_pending_work() takes the is_pending=false / !rejected branch,\ndropping only its own work reference.  This also closes the\nmulti-packet race Sashiko reported on v2: pending is removed from\nthe list before any subsequent packet can find it.\n\nThe pre-existing sk_acceptq_removed() gap on the err \u0026lt; 0 path of\nvmci_transport_recv_listen() that Sashiko also noted is not\nintroduced or changed by this patch.\n\nTested on lts-6.12.79 with KASAN: 52/100 unpatched -\u0026gt; 0/100 patched.(CVE-2026-64115)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: bnep: Fix UAF read of dev-\u0026gt;name\n\nbnep_add_connection() needs to keep holding the bnep_session_sem while\nreading dev-\u0026gt;name (just like bnep_get_connlist() does); otherwise the\nbnep_session() thread can concurrently free the net_device, which can for\nexample be triggered by a concurrent bnep_del_connection().\n\n(This UAF is fairly uninteresting from a security perspective;\ncalling bnep_add_connection() requires passing a capable(CAP_NET_ADMIN)\ncheck. It also requires completely tearing down a netdev during a fairly\ntight race window.)(CVE-2026-64178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - protect service table iterations with service_lock\n\nThe service_table list is protected by service_lock when entries are\nadded or removed (in adf_service_add() and adf_service_remove()), but\nseveral functions iterate over the list without holding this lock.\n\nA concurrent adf_service_register() or adf_service_unregister() call\ncould modify the list during traversal, leading to list corruption or\na use-after-free.\n\nFix this by holding service_lock across all list_for_each_entry()\niterations of service_table in adf_dev_init(), adf_dev_start(),\nadf_dev_stop(), adf_dev_shutdown(), adf_dev_restarting_notify(),\nadf_dev_restarted_notify(), and adf_error_notifier().\n\nThe lock ordering is safe: callers of the static helpers (adf_dev_up()\nand adf_dev_down()) acquire state_lock before service_lock, and no\nevent_hld callback or service_lock holder ever acquires state_lock in\nthe reverse order.(CVE-2026-64305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page\n\nnvmet_execute_disc_get_log_page() validates only the dword alignment\nof the host-supplied Log Page Offset (lpo).  The 64-bit offset is then\nadded to a small kzalloc\u0026apos;d buffer that holds the discovery log page\nand the result is passed straight to nvmet_copy_to_sgl(), which\nmemcpy()s data_len bytes out to the host with no source-side bound\ncheck:\n\n    u64 offset      = nvmet_get_log_page_offset(req-\u0026gt;cmd);  /* 64-bit host */\n    size_t data_len = nvmet_get_log_page_len(req-\u0026gt;cmd);     /* 32-bit host */\n    ...\n    if (offset \u0026amp; 0x3) { ... }                               /* only check */\n    ...\n    alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);\n    buffer = kzalloc(alloc_len, GFP_KERNEL);\n    ...\n    status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);\n\nThe Discovery controller is unauthenticated -- nvmet_host_allowed()\nreturns true unconditionally for the discovery subsystem -- so the call\nis reachable pre-authentication by any TCP/RDMA/FC peer that can reach\nthe nvmet target.  With a discovery log page of ~1 KiB, an attacker\nrequesting up to 4 KiB starting at offset == alloc_len reads the next\nslab page out and gets its content returned over the fabric (an\nempirical run on a default nvmet-tcp loopback target leaked 81\ncanonical kernel pointers in one Get Log Page response).  Pointing the\noffset at unmapped kernel memory faults the in-kernel memcpy and\ncrashes (or panics, on panic_on_oops=1) the target host instead.\n\nThe attacker-controlled source-side offset pattern\n\u0026quot;nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)\u0026quot; is unique\nto nvmet_execute_disc_get_log_page in the entire nvmet codebase: every\nother Get Log Page handler in admin-cmd.c either ignores lpo (and\nsilently starts every response at offset 0) or tracks a local\ndestination offset with a fixed source pointer.\n\nValidate the host-supplied offset against the log page size, cap the\ncopy length to what is actually available, and zero-fill any remainder\nof the host transfer buffer.  The zero-fill matches the existing\nshort-response pattern in nvmet_execute_get_log_changed_ns()\n(admin-cmd.c) and prevents leaking transport SGL contents when the\nhost asks for more bytes than the log page contains.(CVE-2026-64320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: validate sparing table length as an entry count, not a byte count\n\nudf_load_sparable_map() accepts a sparing table when\n\n\tsizeof(*st) + le16_to_cpu(st-\u0026gt;reallocationTableLen) \u0026gt; sb-\u0026gt;s_blocksize\n\nis false, i.e. it treats reallocationTableLen as a number of BYTES that\nmust fit in the block.  But the table is walked as an array of 8-byte\nsparingEntry elements:\n\n\tfor (i = 0; i \u0026lt; le16_to_cpu(st-\u0026gt;reallocationTableLen); i++) {\n\t\tstruct sparingEntry *entry = \u0026amp;st-\u0026gt;mapEntry[i];\n\t\t... entry-\u0026gt;origLocation ...\n\t}\n\nin udf_get_pblock_spar15() and udf_relocate_blocks().  A\nreallocationTableLen of N therefore passes the check whenever\nsizeof(*st) + N \u0026lt;= blocksize, yet the consumers index\nsizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the\nblock.  On a crafted UDF image this is an out-of-bounds read in\nudf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the\nsame length to udf_update_tag(), whose crc_itu_t() reads far past the\nblock, and its memmove() through st-\u0026gt;mapEntry[] is an out-of-bounds\nwrite.\n\nValidate reallocationTableLen as the entry count it is, with\nstruct_size().(CVE-2026-64322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nproc: protect ptrace_may_access() with exec_update_lock (FD links)\n\nproc_pid_get_link() and proc_pid_readlink() currently look up the task from\nthe pid once, then do the ptrace access check on that task, then look up\nthe task from the pid a second time to do the actual access.\nThat\u0026apos;s racy in several ways.\n\nTo fix it, pass the task to the -\u0026gt;proc_get_link() handler, and instead of\nproc_fd_access_allowed(), introduce a new helper call_proc_get_link() that\nlooks up and locks the task, does the access check, and calls\n-\u0026gt;proc_get_link().(CVE-2026-64375)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: mask server-provided mode to 07777 in modefromsid\n\nWhen modefromsid is active, parse_dacl() applies the server-provided\nsub_auth[2] value from the NFS mode SID to cf_mode without masking to\n07777. Apply the correct masking, same as in the read path.(CVE-2026-64379)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: harden POSIX SID length parsing\n\nposix_info_sid_size() reads sid[1] to obtain the subauthority count,\nbut its existing boundary check still accepts buffers with only one\nremaining byte. Require two bytes before reading sid[1] so all client\npaths that reuse the helper reject truncated POSIX SIDs safely.(CVE-2026-64380)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns\n\nIn the analysis pass of $LogFile journal replay, log_replay() copies\nLCNs from each action log record into an existing Dirty Page Table\n(DPT) entry without bounding the destination index. A crafted NTFS\nimage with DPT entry lcns_follow=1 and an action log record with\nlcns_follow=2 produces a kernel slab out-of-bounds write at mount\ntime:\n\n  BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60\n  Write of size 8 at addr ffff8880095e1040 by task mount\n\nTwo attacker-controlled fields can drive j+i past the allocated\npage_lcns[] array:\n\n  1. dp-\u0026gt;lcns_follow (capacity) can be smaller than lrh-\u0026gt;lcns_follow.\n  2. lrh-\u0026gt;target_vcn may be smaller than dp-\u0026gt;vcn, making the u64\n     subtraction wrap to a huge size_t.\n\nValidate target VCN delta and per-record LCN count against the\nDPT entry capacity, bail via the existing out: cleanup label with\n-EINVAL.\n\nThis mirrors the bounds-check pattern added in commit b2bc7c44ed17\n(\u0026quot;fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\u0026quot;)\nand commit 0ca0485e4b2e (\u0026quot;fs/ntfs3: validate rec-\u0026gt;used in\njournal-replay file record check\u0026quot;).(CVE-2026-64432)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path\n\nIn nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected,\nnvmet_req_uninit() is called unconditionally. However, if the command\narrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init()\nhad returned false and percpu_ref_tryget_live() was never executed. The\nunconditional percpu_ref_put() inside nvmet_req_uninit() then causes a\nrefcount underflow, leading to a WARNING in\npercpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and\neventually a permanent workqueue deadlock.\n\nCheck cmd-\u0026gt;flags \u0026amp; NVMET_TCP_F_INIT_FAILED before calling\nnvmet_req_uninit(), matching the existing pattern in\nnvmet_tcp_execute_request().(CVE-2026-64534)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: eir: Fix stack OOB write when prepending the Flags AD\n\neir_create_adv_data() builds the advertising data into a fixed-size\nbuffer (\u0026quot;size\u0026quot;, 31 for the legacy path). It may prepend a 3-byte \u0026quot;Flags\u0026quot;\nAD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies\nthe per-instance data without checking that it still fits:\n\n\tmemcpy(ptr, adv-\u0026gt;adv_data, adv-\u0026gt;adv_data_len);\n\ntlv_data_max_len() only reserves those 3 bytes when the user-supplied\nflags carry a managed-flags bit, so an instance added with flags == 0 is\naccepted with adv_data_len up to the full buffer. At advertise time the\nflags are still prepended, and the memcpy() writes 3 + adv_data_len\nbytes into the size-byte buffer:\n\n  BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)\n  Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65\n  Workqueue: hci0 hci_cmd_sync_work\n   __asan_memcpy (mm/kasan/shadow.c:106)\n   eir_create_adv_data (net/bluetooth/eir.c:301)\n   hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)\n   hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)\n   hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)\n  This frame has 1 object:\n   [32, 64) \u0026apos;cp\u0026apos;\n\nThe \u0026quot;Flags\u0026quot; structure is added by the kernel, not requested by\nuserspace, so only prepend it when it fits together with the instance\nadvertising data; when there is no room for both, drop the flags rather\nthan the user-provided data.\n\nReachable by a local user with CAP_NET_ADMIN owning an LE-only\ncontroller on the legacy advertising path.(CVE-2026-64539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()\n\nl2cap_sock_new_connection_cb() returned l2cap_pi(sk)-\u0026gt;chan after\nrelease_sock(parent). Once the parent lock is dropped the newly\nenqueued child socket sk is reachable via the accept queue, so another\ntask can accept and free it before the callback dereferences sk,\nresulting in a use-after-free.\n\nRework the -\u0026gt;new_connection() op so the core, rather than the callback,\nowns the child channel\u0026apos;s lifetime. The op now receives a pre-allocated\nnew_chan and returns an errno instead of allocating and returning a\nchannel. l2cap_new_connection() allocates the child channel and links\nit into the conn list via __l2cap_chan_add() before invoking the\ncallback, so the conn-list reference keeps the channel alive once\nrelease_sock(parent) exposes the socket to other tasks.\n\nChannel configuration that was duplicated in l2cap_sock_init() and the\nvarious new_connection callbacks is consolidated into\nl2cap_chan_set_defaults(), which now inherits from the parent channel\nwhen one is supplied.(CVE-2026-64557)",
  "id": "OESA-2026-3317",
  "modified": "2026-08-13T13:57:18Z",
  "published": "2026-08-13T13:57:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3317"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31462"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31576"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31577"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31578"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31716"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43211"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52910"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52989"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53256"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53284"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53369"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53375"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53390"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53399"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63794"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63796"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63807"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63823"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63898"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63940"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64113"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64115"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64178"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64305"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64320"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64322"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64375"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64379"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64380"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64432"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64534"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64539"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64557"
    }
  ],
  "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-2026-31462",
    "CVE-2026-31576",
    "CVE-2026-31577",
    "CVE-2026-31578",
    "CVE-2026-31716",
    "CVE-2026-43211",
    "CVE-2026-52910",
    "CVE-2026-52989",
    "CVE-2026-53256",
    "CVE-2026-53284",
    "CVE-2026-53369",
    "CVE-2026-53375",
    "CVE-2026-53390",
    "CVE-2026-53399",
    "CVE-2026-63794",
    "CVE-2026-63796",
    "CVE-2026-63807",
    "CVE-2026-63823",
    "CVE-2026-63898",
    "CVE-2026-63940",
    "CVE-2026-64113",
    "CVE-2026-64115",
    "CVE-2026-64178",
    "CVE-2026-64305",
    "CVE-2026-64320",
    "CVE-2026-64322",
    "CVE-2026-64375",
    "CVE-2026-64379",
    "CVE-2026-64380",
    "CVE-2026-64432",
    "CVE-2026-64534",
    "CVE-2026-64539",
    "CVE-2026-64557"
  ]
}

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-64539.

CVE-2026-64539

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-11-03 21:54

Summary

Security update for the Linux Kernel

Severity

Important

Scope

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

CVE-2026-64539

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-11-03 21:47

Summary

Security update for the Linux Kernel

Severity

Important

Scope

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

CVE-2026-64539

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-11-03 21:47

Summary

Security update for the Linux Kernel

Severity

Important

Scope

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

CVE-2026-64539

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-11-03 21:47

Summary

Security update for the Linux Kernel

Severity

Important

Scope

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

CVE-2026-64539

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-11-03 21:47

Summary

Security update for the Linux Kernel

Severity

Important

Scope

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

CVE-2026-64539

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

Sightings

Author	Source	Type	Date	Other

Nomenclature

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

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

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-64539 (GCVE-0-2026-64539)

OESA-2026-3317 (CVE-2026-31462)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour