{"id":"CVE-2026-99010","kind":"vulnerability","aliases":["CVE-2026-99010"],"related":[],"title":"Linux kernel: Bluetooth RFCOMM leaks a packet buffer per frame after socket close","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: free the skb when the DLC has no owner\n\nrfcomm_recv_data() hands the skb to d->data_ready() and returns 0\nwithout freeing it, so the callback owns the skb from that point on.\nThe tty implementation frees it when the DLC has been detached from its\ndevice:\n\n  static void rfcomm_dev_data_ready(struct rfcomm_dlc *dlc,\n                                    struct sk_buff *skb)\n  {\n          struct rfcomm_dev *dev = dlc->owner;\n\n          if (!dev) {\n                  kfree_skb(skb);\n                  return;\n          }\n\nThe socket implementation returns without freeing it, and the skb is\nleaked.\n\nA connected DLC can have no owner: rfcomm_sock_destruct() clears\nd->owner, while the DLC itself stays on the session until it is closed.\nData frames that arrive in that window still find d->state ==\nBT_CONNECTED in rfcomm_recv_data() and are handed to the callback, one\nleaked skb each.\n\nThe leak does not stop on its own either.  The remote runs out of\ncredits only once RFCOMM_RX_THROTTLED is set, and for a socket the only\nplace that sets it is rfcomm_sk_data_ready() itself, below the return.\nrfcomm_process_dlcs() keeps granting credits, so the remote keeps\nsending and the leak keeps growing.\n\nFree the skb, as the tty side does.","summary":"When a Bluetooth RFCOMM connection has no owning socket, incoming data frames are handed to a callback that never frees them, so the kernel leaks memory on every frame. A nearby remote device that keeps sending data can keep growing that leak until the kernel runs out of memory.","severity":"unknown","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["bluetooth","kernel","linux","runtime","self-hosted"],"not_affected_if":["no-bluetooth","rfcomm-module-not-loaded"],"how_to_check":"- Run `uname -r` and compare against the fixed kernel builds listed by your distribution.\n- Check whether Bluetooth RFCOMM is in use with `lsmod | grep rfcomm`; if the module is not loaded, the code path is not reachable.","fix":"- Update the Linux kernel to a build that includes the upstream commit freeing the skb when the DLC has no owner; the sources do not list fixed version numbers, so unknown.\n- Until patched, unload the RFCOMM module with `modprobe -r rfcomm` on hosts that do not need Bluetooth serial.","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:49+00:00","updated_at":"2026-10-25T04:55:49+00:00","category":"runtime","confidence":0.6,"triage":{"at":"2026-10-25T04:55:49Z","model":"claude-haiku-5-5","output":{"fix":"- Update the Linux kernel to a build that includes the upstream commit freeing the skb when the DLC has no owner; the sources do not list fixed version numbers, so unknown.\n- Until patched, unload the RFCOMM module with `modprobe -r rfcomm` on hosts that do not need Bluetooth serial.","reach":"network","title":"Linux kernel: Bluetooth RFCOMM leaks a packet buffer per frame after socket close","impact":"medium","summary":"When a Bluetooth RFCOMM connection has no owning socket, incoming data frames are handed to a callback that never frees them, so the kernel leaks memory on every frame. A nearby remote device that keeps sending data can keep growing that leak until the kernel runs out of memory.","category":"runtime","nicknames":[],"who_cares":["linux","kernel","bluetooth","self-hosted"],"confidence":0.6,"needs_auth":"no","worst_case":"remote device exhausts kernel memory through repeated leaked buffers","analyst_note":"Confirm affected kernel version ranges and fixed release builds from the NVD entry or the upstream kernel commit.","how_to_check":"- Run `uname -r` and compare against the fixed kernel builds listed by your distribution.\n- Check whether Bluetooth RFCOMM is in use with `lsmod | grep rfcomm`; if the module is not loaded, the code path is not reachable.","needs_analyst":true,"not_affected_if":["no-bluetooth","rfcomm-module-not-loaded"],"who_is_affected":"Systems running a Linux kernel with Bluetooth RFCOMM support where a remote device can open an RFCOMM channel, including those with the rfcomm module loaded. Hosts without Bluetooth hardware or with the RFCOMM module absent are not exposed. The sources do not say which kernel versions are affected.","user_interaction":"no","needs_special_setup":"yes","severity_if_unknown":"unknown"},"cost_usd":0.000713,"input_tokens":3721,"output_tokens":682,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'-2026':15A,18A '-99010':16A,19A '0':109C 'arriv':203C 'bluetooth':3A,20B,29B,86C 'bt':211C 'buff':149C 'buffer':8A 'callback':43B,115C,222C 'clear':185C 'close':13A,199C 'connect':31B,176C,212C 'credit':241C,273C 'cve':14A,17A 'd':104C,186C,209C 'data':37B,63B,99C,105C,141C,200C,216C,262C 'destruct':184C 'detach':133C 'dev':140C,153C,154C,158C 'devic':59B,136C 'dlc':93C,130C,145C,146C,155C,177C,190C 'dlcs':270C 'either':235C 'everi':54B 'find':208C 'follow':81C 'frame':10A,38B,55B,201C 'free':46B,88C,111C,126C,168C,284C 'grant':272C 'grow':66B,283C 'hand':40B,100C,219C 'host':26B 'implement':125C,165C 'incom':36B 'keep':61B,65B,271C,277C,282C 'kernel':2A,21B,50B,71B,79C 'kfree':159C 'leak':5A,51B,68B,174C,224C,228C,281C 'linux':1A,22B,78C 'memori':52B,75B 'nearbi':57B 'never':45B 'one':223C 'own':34B,116C 'owner':96C,156C,181C,187C 'packet':7A 'per':9A 'place':255C 'point':121C 'process':269C 'readi':106C,142C,263C 'recv':98C,215C 'remot':58B,237C,276C 'resolv':85C 'return':108C,162C,166C,267C 'rfcomm':4A,30B,87C,97C,139C,144C,152C,182C,214C,244C,260C,268C 'run':72B,238C 'runtim':23B 'rx':245C 'self':25B 'self-host':24B 'send':62B,278C 'session':195C 'set':248C,257C 'side':290C 'sk':148C,261C 'skb':90C,102C,118C,150C,160C,161C,172C,225C,286C 'sock':183C 'socket':12A,35B,164C,252C 'state':210C 'static':137C 'stay':192C 'still':207C 'stop':231C 'struct':143C,147C,151C 'throttl':246C 'tti':124C,289C 'void':138C 'vulner':82C 'window':206C 'without':110C,167C","nicknames":[],"mitigations":[],"who_affected":"Systems running a Linux kernel with Bluetooth RFCOMM support where a remote device can open an RFCOMM channel, including those with the rfcomm module loaded. Hosts without Bluetooth hardware or with the RFCOMM module absent are not exposed. The sources do not say which kernel versions are affected.","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-99010","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99010","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}],"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"}