AZL-110858: CVE-2026-99010 affecting package kernel 6.6.157.1-1

Q: Which RFCOMM users are exposed to the leak?

The affected path is the RFCOMM socket implementation. A connected DLC is exposed after its socket destructor clears the DLC owner while the DLC remains on the RFCOMM session; the tty implementation frees the skb in the equivalent no-owner case.

Q: What does an attacker need to do to trigger continued memory growth?

A remote Bluetooth peer must be able to send RFCOMM data frames to a connected DLC during the window in which the DLC has no owner. Each arriving frame is passed to the socket callback without its skb being freed.

Q: Will RFCOMM flow control eventually stop the leak?

No. The socket callback returns before setting RFCOMM_RX_THROTTLED, while RFCOMM processing continues granting credits, allowing the remote peer to keep sending frames and the leaked skb allocation to keep growing.

Published Oct 23, 2026

Updated

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

Bluetooth: RFCOMM: free the skb when the DLC has no owner

rfcommrecvdata() hands the skb to d->dataready() and returns 0 without freeing it, so the callback owns the skb from that point on. The tty implementation frees it when the DLC has been detached from its device:

static void rfcommdevdataready(struct rfcommdlc dlc, struct skbuff skb) { struct rfcommdev dev = dlc->owner;

if (!dev) { kfreeskb(skb); return; }

The socket implementation returns without freeing it, and the skb is leaked.

A connected DLC can have no owner: rfcommsockdestruct() clears d->owner, while the DLC itself stays on the session until it is closed. Data frames that arrive in that window still find d->state == BTCONNECTED in rfcommrecvdata() and are handed to the callback, one leaked skb each.

The leak does not stop on its own either. The remote runs out of credits only once RFCOMMRXTHROTTLED is set, and for a socket the only place that sets it is rfcommskdataready() itself, below the return. rfcommprocessdlcs() keeps granting credits, so the remote keeps sending and the leak keeps growing.

Free the skb, as the tty side does.

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-99010

Frequently Asked Questions

Which RFCOMM users are exposed to the leak?

The affected path is the RFCOMM socket implementation. A connected DLC is exposed after its socket destructor clears the DLC owner while the DLC remains on the RFCOMM session; the tty implementation frees the skb in the equivalent no-owner case.

What does an attacker need to do to trigger continued memory growth?

A remote Bluetooth peer must be able to send RFCOMM data frames to a connected DLC during the window in which the DLC has no owner. Each arriving frame is passed to the socket callback without its skb being freed.

Will RFCOMM flow control eventually stop the leak?

No. The socket callback returns before setting RFCOMM_RX_THROTTLED, while RFCOMM processing continues granting credits, allowing the remote peer to keep sending frames and the leaked skb allocation to keep growing.

AZL-110858: CVE-2026-99010 affecting package kernel 6.6.157.1-1

Affected Software

Event History

Child vulnerabilities

Frequently Asked Questions

Which RFCOMM users are exposed to the leak?

What does an attacker need to do to trigger continued memory growth?

Will RFCOMM flow control eventually stop the leak?

Company

Resources

Contact

Frequently Asked Questions

Which RFCOMM users are exposed to the leak?

What does an attacker need to do to trigger continued memory growth?

Will RFCOMM flow control eventually stop the leak?