AZL-110852: CVE-2026-99008 affecting package kernel 6.6.157.1-1

Q: What conditions are required to trigger the crash?

An RFCOMM device must be added to the RFCOMM device list, but registration of its tty device must fail before dev->tty_dev is set. A subsequent open and close of the corresponding /dev/rfcommN device can then cause rfcomm_dev_shutdown() to dereference the NULL tty_dev pointer.

Published Oct 23, 2026

Updated

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

Bluetooth: RFCOMM: Fix NULL ttydev dereference in rfcommdevshutdown

syzbot hit a NULL pointer dereference in rfcommdevshutdown() when an RFCOMM tty is closed.

rfcommdevadd() puts the new device on rfcommdevlist first and only then registers the tty device and saves it in dev->ttydev. If that registration fails, dev->ttydev is never set at all. The device can be looked up in the meantime, so an open() of /dev/rfcommN gets through rfcommttyinstall() and attaches to it. When that tty is closed again, rfcommdevshutdown() uses dev->ttydev without checking it:

Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047] RIP: 0010:rfcommdevshutdown+0x48/0xb0 net/bluetooth/rfcomm/tty.c:131 Call Trace: ttyportshutdown+0x1bf/0x220 drivers/tty/ttyport.c:372 ttyportclose+0x4e/0x150 drivers/tty/ttyport.c:705 ttyrelease+0x359/0x1670 drivers/tty/ttyio.c:1718 fput+0x418/0xa50 fs/filetable.c:512

rfcommdevdestruct() already copes with a NULL dev->ttydev. Add the same check to rfcommdevshutdown(), so the tty device is only moved when it was actually registered.

Affected Software

1 affected component

azure-linux/kernel<=6.6.157.1-1

Event History

Oct 23, 2026

Advisory Published

via OSV·01:17 PM

Data Sourced

via OSV·01:17 PM

DescriptionAffected Software

Child vulnerabilities

Contains the following vulnerabilities.

CVE-2026-99008

Frequently Asked Questions

What conditions are required to trigger the crash?

An RFCOMM device must be added to the RFCOMM device list, but registration of its tty device must fail before dev->tty_dev is set. A subsequent open and close of the corresponding /dev/rfcommN device can then cause rfcomm_dev_shutdown() to dereference the NULL tty_dev pointer.

What is the practical impact of successful triggering?

The described result is a kernel NULL pointer dereference during RFCOMM tty shutdown, producing an Oops/general protection fault. This can disrupt the affected system through a kernel crash or fault condition.

How can I determine whether a system has encountered this issue?

Look for kernel logs showing a NULL pointer dereference or general protection fault in rfcomm_dev_shutdown(), with stack frames such as tty_port_shutdown, tty_port_close, tty_release, and __fput. The reported fault occurs at net/bluetooth/rfcomm/tty.c:131.

AZL-110852: CVE-2026-99008 affecting package kernel 6.6.157.1-1

Affected Software

Event History

Child vulnerabilities

Frequently Asked Questions

What conditions are required to trigger the crash?

What is the practical impact of successful triggering?

How can I determine whether a system has encountered this issue?

Company

Resources

Contact

Frequently Asked Questions

What conditions are required to trigger the crash?

What is the practical impact of successful triggering?

How can I determine whether a system has encountered this issue?