GHSA-RXG5-JR9R-8PC7

Vulnerability from github – Published: 2026-07-27 21:31 – Updated: 2026-07-30 06:32
VLAI
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.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-64539"
  ],
  "database_specific": {
    "cwe_ids": [],
    "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-07-30T06:32:33Z",
  "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/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"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…