{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.113-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.2.10-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: RFCOMM: Fix initial port reference race  For RFCOMM_RELEASE_ONHUP devices, rfcomm_tty_install() and __rfcomm_release_dev() both use RFCOMM_TTY_OWNED to decide who drops the initial tty_port reference. The release path tests the bit separately from the install path setting it, so both can drop that reference.  The synchronous hangup does not prevent this race: port-\u003etty is not assigned until tty_port_open(), after installation. The following interleaving is possible:    1. Install and release each obtain a reference with rfcomm_dev_get().   2. Release observes RFCOMM_TTY_OWNED clear.   3. Install sets RFCOMM_TTY_OWNED and drops the initial reference.   4. Release drops the same initial reference again.   5. TTY cleanup drops its reference and frees the device.   6. Release performs its final tty_port_put() on the freed port.  KASAN reported:    BUG: KASAN: slab-use-after-free in tty_port_put+0x22/0x190   Write of size 4 at addr ffff8881001d3d5c by task poc/92    Call Trace:    tty_port_put+0x22/0x190    rfcomm_dev_ioctl+0x1d4/0x1930    sock_do_ioctl+0x110/0x260    sock_ioctl+0x380/0x590    __x64_sys_ioctl+0x134/0x1c0    Allocated by task 88:    rfcomm_dev_ioctl+0x8f6/0x1930    sock_do_ioctl+0x110/0x260    sock_ioctl+0x380/0x590    __x64_sys_ioctl+0x134/0x1c0    Freed by task 65:    kfree+0x131/0x3c0    rfcomm_dev_destruct+0x23b/0x2f0    release_one_tty+0xc1/0x370    process_one_work+0x661/0x1090  Use test_and_set_bit() in both paths so that only the caller that changes RFCOMM_TTY_OWNED from clear to set drops the initial reference. Each path keeps its own lookup reference until release or TTY cleanup, preserving the existing callback ordering and error handling.",
  "id": "DEBIAN-CVE-2026-98739",
  "modified": "2026-10-19T04:47:26.277500311Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-98739"
    }
  ],
  "upstream": [
    "CVE-2026-98739"
  ]
}