🇰🇷 한글 설명
Linux 커널 Bluetooth RFCOMM 모듈에서 rfcomm_recv_data()가 skb를 콜백에 넘긴 뒤 소유자(owner)가 없는 DLC의 경우 해당 skb를 해제하지 않아 메모리 누수가 발생합니다. 소켓 구현은 skb를 해제하지 않으며, 원격 측이 크레딧을 계속 부여받아 누수가 지속적으로 증가할 수 있습니다. 해결책은 tty 구현과 동일하게 skb를 해제하는 것입니다.
💡 쉬운 설명
블루투스 연결에서 데이터를 받을 때 사용한 메모리 조각이 제대로 반환되지 않아 시간이 지날수록 시스템 메모리가 조금씩 낭비됩니다. 상대 기기가 계속 데이터를 보내면 누수가 멈추지 않고 커질 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: free the skb when the DLC has no owner
rfcomm_recv_data() hands the skb to d->data_ready() 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 rfcomm_dev_data_ready(struct rfcomm_dlc *dlc,
struct sk_buff *skb)
{
struct rfcomm_dev *dev = dlc->owner;
if (!dev) {
kfree_skb(skb);
return;
}
The socket implementation returns without freeing it, and the skb is
leaked.
A connected DLC can have no owner: rfcomm_sock_destruct() 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 ==
BT_CONNECTED in rfcomm_recv_data() 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 RFCOMM_RX_THROTTLED is set, and for a socket the only
place that sets it is rfcomm_sk_data_ready() itself, below the return.
rfcomm_process_dlcs() keeps granting credits, so the remote keeps
sending and the leak keeps growing.
Free the skb, as the tty side does.
📍 영향받는 시스템
Linux 커널의 Bluetooth RFCOMM 소켓 구현을 포함하는 버전 (정확한 영향 버전은 공개된 패치 정보 확인 필요)
⚔️ 공격 벡터
인접한 블루투스 장치가 RFCOMM 연결을 맺은 뒤 소켓 소유자가 없는 DLC 상태에서 데이터 프레임을 지속적으로 전송하여 메모리 고갈(DoS)을 유발
🛡️ 대응 방법
Linux 커널을 해당 CVE의 수정 패치가 포함된 최신 안정 버전으로 업데이트
🔧 검증 코드
커널 버전을 확인하고 최신 보안 업데이트 적용 여부를 배포판 공지와 대조하며, rfcomm 모듈이 로드되지 않았다면 이 취약점에 노출되지 않은 것으로 판단합니다.
uname -r && (lsmod | grep -i rfcomm || echo 'rfcomm 모듈 미로드')