From nobody Mon Jun 8 23:56:24 2026 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B0B7937D11D for ; Mon, 25 May 2026 11:05:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779707102; cv=none; b=X4go+nF3M8z3ia6UIGpaAK+kfmYBqHmJzWPxH0YhrEHd686y580uQSycrNDArd+dQ8Ro2GYWNP/OL1gNHYAzK31lRKvWM5n9c5vMe3oExgskMM+cb1YoYbk+RftvHr56CGWrd6Dj0cVm+TLFiDQWv0qQwLtc6B4xeWx2FlnFbpo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779707102; c=relaxed/simple; bh=APGIhPHWPR/+wOGzlnoG4GOHhlB1pMxWopND9p9UWfQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=ov1kSzrdQb191q2Ml6JTHPUg2mFh80pNCqd7lO+VDxO8nAp9tFxjFJHE2pgI5MMiAYOB9yoBv5B0+e4BI7mFS2Po8BVYnmQ59C7L25VdrRb2Xl1vylh00J/XONg1fMDAQgjZ8bus2Zn7iiB7mkXtKNja6jL2in1xp5lxmNiQmSo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=a5tDeD3v; arc=none smtp.client-ip=209.85.214.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="a5tDeD3v" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2bea7176c72so31518825ad.0 for ; Mon, 25 May 2026 04:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779707100; x=1780311900; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=Ev+qvGFv8hIErwC5zu3VS01UuSRGE6RIayOr3UZ1lFQ=; b=a5tDeD3vrbugEYuVAUwyeHSyRBfggxpnp3zf+xgSzkbK3t0aNY1YeKsJuyv1XSZP6m 9+zD1uxLJ2QSrtHQP1Z6QUObTHJKZwD9f5yWnlW+BeqN/CGy8BidUi7cgJTRmihcgdds GXeIbUvqIGCLJYn8c+dERKNJ04dykm00Lcxg+gISxIX45TJgM1J2JdMEfLOhyeUadgFk vjEkUXcmDEY5Y6KSlnmojO+mTq5FWLtK6BfYhCdScvLirnZfL8P4AHJ9nTOI7zitbqOW O4ur8fXGPppzwB+Wrrynzciv9AEVrX/EFrS/cLZ2/CG0krgv7EgbdPNp6ysjh17kR2ID X5ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779707100; x=1780311900; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Ev+qvGFv8hIErwC5zu3VS01UuSRGE6RIayOr3UZ1lFQ=; b=pDo18UJAHjrzxcGLM2cuM4XNnbNS/J2SB+IMaMzMVahvSVriaWVAKWm/Q3GYPtlW8G bhvmASOZ58O8lp8Lfy5G72t4yTSlFDi8kTm8EyCf7iEwuThzPkVFTPKzO/kfK4IJi2zp WE7TDd1shZNK/5NtGIT8qCMtN3tT4r1Pkp5aEmyzhyOLFJ0wee2cYxFMCC4A50B5YY5A YOPNR1RGIsH5geZqvmaSxbqt8YupPta3w5cv252wSLpu9YrDgnq1EJAqQ2VQQumqCa32 7PsdE49LL2VPMQDKpjgjYbwwQqRY+qmIu+7SHGJghShLeXSCa2fMRVfnWmSYztGU8wYD kQZw== X-Forwarded-Encrypted: i=1; AFNElJ+iMPZ7spmU/pW+g6GYaxJe5wUmMUlZwFSgN2rPTWmFWCBJng9Jr2ecow2Oaw036bqch0GhSeaq7zndsx4=@vger.kernel.org X-Gm-Message-State: AOJu0YztetieGXu1hPF5+gFb20ckQlsTctkVMsFl9EUAG7WFWv5RhTkA A2ZoDp+Vj+QzPJCAWTOznuugKbGCVPDtvjSWkdOUsZTedldbtAz3MpTU X-Gm-Gg: Acq92OFnZnwRIv30LYXzmpA6M64ppW/8xJR5yizvdTk0TddvbV5Fak9AWUQrkLrJYL8 AiHnjXEy1QzC5y5e1MuynQMOtrrWOTIhbWvrchX+fbgvYFlHp/ADu7Moc3XKCjpv7xm3aqE1mmP 2pyWmgHGiyjtDQPryOJx0A6ZP8oWY8cQ42AKVVkmIWNxiSi6UbKOdn86hdx94YRGD5S6mk7vggx Ei7oBhupBlHXGfgG1O+Y1jZBzzi+ysCKSVBVAte6VDZR2pBN1A/0nJR1Hv6Hw6/WfGiW1pCgGiw xvm0SKH0hFVyU+hRnzqW3ReErVg4QuD5g+PT9S2Uk714PuC2migIFpM5/WXORJG4dw2DiGh35Xv FIUwiks+Y1NWXKulMnhdWNsH+d/qZqcJ5gYqtoMlXk08RfFDbFOT2QCyh5UemEkMbCWBAzsZ7hC yednbC27Gh+244M7dv8i/30egyq1YLkfJmk9+jiAoCG7lbbPI= X-Received: by 2002:a17:902:db0d:b0:2bc:ac76:c1cf with SMTP id d9443c01a7336-2beb0698547mr158655125ad.24.1779707099972; Mon, 25 May 2026 04:04:59 -0700 (PDT) Received: from fedora ([61.74.238.173]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2beb5695a29sm88776955ad.11.2026.05.25.04.04.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 May 2026 04:04:59 -0700 (PDT) From: SeungJu Cheon To: linux-bluetooth@vger.kernel.org Cc: marcel@holtmann.org, luiz.dentz@gmail.com, pmenzel@molgen.mpg.de, me@brighamcampbell.com, linux-kernel@vger.kernel.org, linux-kernel-mentees@lists.linux.dev, skhan@linuxfoundation.org, SeungJu Cheon , Muhammad Bilal Subject: [PATCH v3] Bluetooth: RFCOMM: validate skb length in MCC handlers Date: Mon, 25 May 2026 20:04:43 +0900 Message-ID: <20260525110443.139485-1-suunj1331@gmail.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Muhammad Bilal Signed-off-by: SeungJu Cheon --- v3: - Apply skb_pull_data() in rfcomm_recv_mcc() before accessing the MCC header - Return -EILSEQ instead of -EINVAL for malformed frames v2: - Use skb_pull_data() instead of manual length checks (Luiz) - Add MCC header length validation in rfcomm_recv_mcc() (Paul) - Allow 1-byte RPN requests per ETSI TS 07.10 (Paul) Testing: Tested under QEMU with VHCI and KASAN enabled by injecting both well-formed and malformed RFCOMM MCC frames. Well-formed PN/MSC/RLS frames and both valid RPN variants (full 8-byte form and 1-byte query form) are parsed identically to the pre-patch behavior. The following malformed frames are rejected before reaching the MCC sub-handlers: - truncated MCC headers - PN/MSC/RLS/RPN payloads shorter than the fixed struct size - invalid intermediate RPN lengths (len !=3D 1 && len < 8) - MCC payload lengths larger than the actual skb data Frames with cr=3D0 are still silently dropped, and oversized frames continue to ignore trailing bytes as before. net/bluetooth/rfcomm/core.c | 67 +++++++++++++++++++++++++++---------- 1 file changed, 49 insertions(+), 18 deletions(-) diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c index d11bd5337d57..364b9381c2dc 100644 --- a/net/bluetooth/rfcomm/core.c +++ b/net/bluetooth/rfcomm/core.c @@ -1431,10 +1431,15 @@ static int rfcomm_apply_pn(struct rfcomm_dlc *d, in= t cr, struct rfcomm_pn *pn) =20 static int rfcomm_recv_pn(struct rfcomm_session *s, int cr, struct sk_buff= *skb) { - struct rfcomm_pn *pn =3D (void *) skb->data; + struct rfcomm_pn *pn; struct rfcomm_dlc *d; - u8 dlci =3D pn->dlci; + u8 dlci; + + pn =3D skb_pull_data(skb, sizeof(*pn)); + if (!pn) + return -EILSEQ; =20 + dlci =3D pn->dlci; BT_DBG("session %p state %ld dlci %d", s, s->state, dlci); =20 if (!dlci) @@ -1483,8 +1488,8 @@ static int rfcomm_recv_pn(struct rfcomm_session *s, i= nt cr, struct sk_buff *skb) =20 static int rfcomm_recv_rpn(struct rfcomm_session *s, int cr, int len, stru= ct sk_buff *skb) { - struct rfcomm_rpn *rpn =3D (void *) skb->data; - u8 dlci =3D __get_dlci(rpn->dlci); + struct rfcomm_rpn *rpn; + u8 dlci; =20 u8 bit_rate =3D 0; u8 data_bits =3D 0; @@ -1495,15 +1500,16 @@ static int rfcomm_recv_rpn(struct rfcomm_session *s= , int cr, int len, struct sk_ u8 xoff_char =3D 0; u16 rpn_mask =3D RFCOMM_RPN_PM_ALL; =20 - BT_DBG("dlci %d cr %d len 0x%x bitr 0x%x line 0x%x flow 0x%x xonc 0x%x xo= ffc 0x%x pm 0x%x", - dlci, cr, len, rpn->bit_rate, rpn->line_settings, rpn->flow_ctrl, - rpn->xon_char, rpn->xoff_char, rpn->param_mask); + if (len =3D=3D 1) { + rpn =3D skb_pull_data(skb, 1); + if (!rpn) + return -EILSEQ; =20 - if (!cr) - return 0; + dlci =3D __get_dlci(rpn->dlci); + + if (!cr) + return 0; =20 - if (len =3D=3D 1) { - /* This is a request, return default (according to ETSI TS 07.10) settin= gs */ bit_rate =3D RFCOMM_RPN_BR_9600; data_bits =3D RFCOMM_RPN_DATA_8; stop_bits =3D RFCOMM_RPN_STOP_1; @@ -1514,6 +1520,19 @@ static int rfcomm_recv_rpn(struct rfcomm_session *s,= int cr, int len, struct sk_ goto rpn_out; } =20 + rpn =3D skb_pull_data(skb, sizeof(*rpn)); + if (!rpn) + return -EILSEQ; + + dlci =3D __get_dlci(rpn->dlci); + + BT_DBG("dlci %d cr %d len 0x%x bitr 0x%x line 0x%x flow 0x%x xonc 0x%x xo= ffc 0x%x pm 0x%x", + dlci, cr, len, rpn->bit_rate, rpn->line_settings, rpn->flow_ctrl, + rpn->xon_char, rpn->xoff_char, rpn->param_mask); + + if (!cr) + return 0; + /* Check for sane values, ignore/accept bit_rate, 8 bits, 1 stop bit, * no parity, no flow control lines, normal XON/XOFF chars */ =20 @@ -1589,9 +1608,14 @@ static int rfcomm_recv_rpn(struct rfcomm_session *s,= int cr, int len, struct sk_ =20 static int rfcomm_recv_rls(struct rfcomm_session *s, int cr, struct sk_buf= f *skb) { - struct rfcomm_rls *rls =3D (void *) skb->data; - u8 dlci =3D __get_dlci(rls->dlci); + struct rfcomm_rls *rls; + u8 dlci; =20 + rls =3D skb_pull_data(skb, sizeof(*rls)); + if (!rls) + return -EILSEQ; + + dlci =3D __get_dlci(rls->dlci); BT_DBG("dlci %d cr %d status 0x%x", dlci, cr, rls->status); =20 if (!cr) @@ -1608,10 +1632,15 @@ static int rfcomm_recv_rls(struct rfcomm_session *s= , int cr, struct sk_buff *skb =20 static int rfcomm_recv_msc(struct rfcomm_session *s, int cr, struct sk_buf= f *skb) { - struct rfcomm_msc *msc =3D (void *) skb->data; + struct rfcomm_msc *msc; struct rfcomm_dlc *d; - u8 dlci =3D __get_dlci(msc->dlci); + u8 dlci; + + msc =3D skb_pull_data(skb, sizeof(*msc)); + if (!msc) + return -EILSEQ; =20 + dlci =3D __get_dlci(msc->dlci); BT_DBG("dlci %d cr %d v24 0x%x", dlci, cr, msc->v24_sig); =20 d =3D rfcomm_dlc_get(s, dlci); @@ -1644,17 +1673,19 @@ static int rfcomm_recv_msc(struct rfcomm_session *s= , int cr, struct sk_buff *skb =20 static int rfcomm_recv_mcc(struct rfcomm_session *s, struct sk_buff *skb) { - struct rfcomm_mcc *mcc =3D (void *) skb->data; + struct rfcomm_mcc *mcc; u8 type, cr, len; =20 + mcc =3D skb_pull_data(skb, sizeof(*mcc)); + if (!mcc) + return -EILSEQ; + cr =3D __test_cr(mcc->type); type =3D __get_mcc_type(mcc->type); len =3D __get_mcc_len(mcc->len); =20 BT_DBG("%p type 0x%x cr %d", s, type, cr); =20 - skb_pull(skb, 2); - switch (type) { case RFCOMM_PN: rfcomm_recv_pn(s, cr, skb); --=20 2.52.0