{"id":"CVE-2026-99008","kind":"vulnerability","aliases":["CVE-2026-99008"],"related":[],"title":"Linux kernel: Bluetooth RFCOMM NULL pointer crash when tty closed","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: Fix NULL tty_dev dereference in rfcomm_dev_shutdown\n\nsyzbot hit a NULL pointer dereference in rfcomm_dev_shutdown() when an\nRFCOMM tty is closed.\n\nrfcomm_dev_add() puts the new device on rfcomm_dev_list first and only\nthen registers the tty device and saves it in dev->tty_dev. If that\nregistration fails, dev->tty_dev is never set at all. The device can be\nlooked up in the meantime, so an open() of /dev/rfcommN gets through\nrfcomm_tty_install() and attaches to it. When that tty is closed again,\nrfcomm_dev_shutdown() uses dev->tty_dev without checking it:\n\n  Oops: general protection fault, probably for non-canonical address\n  KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047]\n  RIP: 0010:rfcomm_dev_shutdown+0x48/0xb0 net/bluetooth/rfcomm/tty.c:131\n  Call Trace:\n   tty_port_shutdown+0x1bf/0x220 drivers/tty/tty_port.c:372\n   tty_port_close+0x4e/0x150 drivers/tty/tty_port.c:705\n   tty_release+0x359/0x1670 drivers/tty/tty_io.c:1718\n   __fput+0x418/0xa50 fs/file_table.c:512\n\nrfcomm_dev_destruct() already copes with a NULL dev->tty_dev. Add the\nsame check to rfcomm_dev_shutdown(), so the tty device is only moved\nwhen it was actually registered.","summary":"When RFCOMM device registration fails in the Linux kernel Bluetooth stack, the device can still be opened and later closed, which dereferences a NULL pointer and crashes the kernel. The sources describe a kernel oops (general protection fault), and the fix adds a NULL check in rfcomm_dev_shutdown().","severity":"unknown","cvss":null,"epss":0.00209,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["bluetooth","linux-kernel","runtime"],"not_affected_if":["no-bluetooth-rfcomm"],"how_to_check":"- unknown","fix":"- Update the Linux kernel to a release that includes the RFCOMM NULL tty_dev check in rfcomm_dev_shutdown() (fixed version not stated in the sources)","status":"open","published_at":"2026-10-23T13:17:23+00:00","first_seen_at":"2026-10-23T21:57:33+00:00","triaged_at":"2026-10-25T04:55:51+00:00","updated_at":"2026-10-25T12:38:50+00:00","category":"runtime","confidence":0.5,"triage":{"at":"2026-10-25T04:55:51Z","model":"claude-haiku-5-5","output":{"fix":"- Update the Linux kernel to a release that includes the RFCOMM NULL tty_dev check in rfcomm_dev_shutdown() (fixed version not stated in the sources)","reach":"local","title":"Linux kernel: Bluetooth RFCOMM NULL pointer crash when tty closed","impact":"medium","summary":"When RFCOMM device registration fails in the Linux kernel Bluetooth stack, the device can still be opened and later closed, which dereferences a NULL pointer and crashes the kernel. The sources describe a kernel oops (general protection fault), and the fix adds a NULL check in rfcomm_dev_shutdown().","category":"runtime","nicknames":[],"who_cares":["linux-kernel","bluetooth"],"confidence":0.5,"needs_auth":"unknown","worst_case":"local user crashes the kernel via NULL dereference","analyst_note":"Find the affected and fixed kernel versions and whether the bug is reachable without privileges, from the NVD entry or the upstream kernel commit.","how_to_check":"- unknown","needs_analyst":true,"not_affected_if":["no-bluetooth-rfcomm"],"who_is_affected":"Systems running a Linux kernel with Bluetooth RFCOMM support where a local user can open /dev/rfcommN after a failed device registration. The sources do not say which kernel versions are affected, and it is unknown whether a default configuration exposes the path.","user_interaction":"no","needs_special_setup":"unknown","severity_if_unknown":"low"},"cost_usd":0.000649,"input_tokens":3815,"output_tokens":535,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'+0':210C,219C,226C,232C,237C '-2026':12A,15A '-99008':13A,16A '/dev/rfcommn':159C '0010':206C '0x0000000000000040':203C '0x0000000000000040-0x0000000000000047':202C '0x0000000000000047':204C '131':213C '1718':235C '372':222C '512':240C '705':229C 'actual':270C 'add':63B,110C,252C 'address':194C 'alreadi':244C 'attach':166C 'bluetooth':3A,17B,31B,81C 'call':214C 'canon':193C 'check':66B,183C,255C 'close':10A,41B,107C,173C,225C 'cope':245C 'crash':7A,48B 'cve':11A,14A 'deref':199C 'derefer':43B,87C,97C 'describ':53B 'destruct':243C 'dev':69B,86C,90C,100C,109C,117C,131C,133C,138C,140C,176C,179C,181C,208C,242C,249C,251C,258C 'devic':24B,34B,114C,126C,147C,263C 'drivers/tty/tty_io.c':234C 'drivers/tty/tty_port.c':221C,228C 'fail':26B,137C 'fault':59B,188C 'first':119C 'fix':62B,83C 'follow':76C 'fput':236C 'fs/file_table.c':239C 'general':57B,186C 'get':160C 'hit':93C 'instal':164C 'kasan':195C 'kernel':2A,20B,30B,50B,55B,74C 'later':40B 'linux':1A,19B,29B,73C 'linux-kernel':18B 'list':118C 'look':150C 'meantim':154C 'move':266C 'net/bluetooth/rfcomm/tty.c':212C 'never':142C 'new':113C 'non':192C 'non-canon':191C 'null':5A,45B,65B,84C,95C,197C,248C 'null-ptr-deref':196C 'oop':56B,185C 'open':38B,157C 'pointer':6A,46B,96C 'port':217C,224C 'probabl':189C 'protect':58B,187C 'ptr':198C 'put':111C 'rang':201C 'regist':123C,271C 'registr':25B,136C 'releas':231C 'resolv':80C 'rfcomm':4A,23B,68B,82C,89C,99C,104C,108C,116C,162C,175C,207C,241C,257C 'rip':205C 'runtim':21B 'save':128C 'set':143C 'shutdown':70B,91C,101C,177C,209C,218C,259C 'sourc':52B 'stack':32B 'still':36B 'syzbot':92C 'trace':215C 'tti':9A,85C,105C,125C,132C,139C,163C,171C,180C,216C,223C,230C,250C,262C 'use':178C 'vulner':77C 'without':182C 'x1bf/0x220':220C 'x359/0x1670':233C 'x418/0xa50':238C 'x48/0xb0':211C 'x4e/0x150':227C","nicknames":[],"mitigations":[],"who_affected":"Systems running a Linux kernel with Bluetooth RFCOMM support where a local user can open /dev/rfcommN after a failed device registration. The sources do not say which kernel versions are affected, and it is unknown whether a default configuration exposes the path.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-23T13:17:23+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-99008","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99008","severity":null,"published_at":"2026-10-23T13:17:23+00:00","modified_at":"2026-10-23T13:17:23+00:00","first_seen_at":"2026-10-23T21:57:33+00:00","fetched_at":"2026-10-23T22:29:03+00:00","note":null},{"source":"epss","external_id":"CVE-2026-99008","url":"https://api.first.org/data/v1/epss?cve=CVE-2026-99008","severity":null,"published_at":null,"modified_at":null,"first_seen_at":"2026-10-25T12:38:50+00:00","fetched_at":"2026-10-25T12:38:50+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}