From nobody Mon May 25 04:33:50 2026 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 44EA3257855 for ; Tue, 19 May 2026 01:23:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779153785; cv=none; b=uM8txUUDs6w3vUd2asb7YWRWO2ZacmieIUBKdQbJXv/SN05ZGM2IY2awFAmc1JNzVvHgUiUAAXr6GSxM/HI6HUpolm1z/k+nMFLtlI5RM4CwVZ8jgnz68WZ0ghVuTVgo8jPmnECMTo5SxvqrWQZT9RD/gHs1c5MG1JGTGBNOyVI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779153785; c=relaxed/simple; bh=VeXWv1s7VjIj16f62IeF3AHt/aQZkX3KYCOUQT1VU0s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=h0CtbN819FwDoM/3U0/nlN04j20u1BhW+ccl53eCnEszzcmMgjYIXM2RI9e1qQEyfX8LXEp4IVoUn3pcdkLRQ0dqtP9dh3Sdk5Kjx1YwQHuzpBzYqp6m1TXJKVCUxwsmZzVVEp6DQMlhCLEE5Vi6fhund81MdOd1n8jxdd0xhzs= 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=DjiWy7Gt; arc=none smtp.client-ip=209.85.128.54 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="DjiWy7Gt" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-48d102471a4so23361745e9.2 for ; Mon, 18 May 2026 18:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779153783; x=1779758583; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=JsZN4KBbcJX1FoY6/tUwgCFPOKTIi4RrtSn6JymXQo4=; b=DjiWy7Gt2o13EAY6WreAHqQWHjsPARbZ3CbVns8iFOnfswX4upOkm0Vj1eqVk0TJom VzBsOUAcToXs2dIekG088Cc94uQ4DkiBAZwlVSDVfVdJmmpbqHAP9/evg995SToNLvOP 7ZzePy7P5OJBn0GnaTip+Uf6FSPt5ihuJtrfoEIBJxz6AboQH/we9q5hGirTeCAgGsOn Rj5P4OVcGbZ6ed+J8Q2+gs5qmDySAiNjJo8c7XOsSuiepUSwlWXttf8Zb9Z/JfCsSj8S 7HH7VxFjm9A3VV9XxIH+dDfYCKp2eLB8vptaQVtAxG4OqGaUNdkoZ9CfpmKvh/xHM6cM r7wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779153783; x=1779758583; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=JsZN4KBbcJX1FoY6/tUwgCFPOKTIi4RrtSn6JymXQo4=; b=NxpskERTscVDfkVQyS5zqg/GUr6WwSm9BFUL/AcgU8tr/wSdvCSQgUvipvWuFsGsR6 UqXeGsOwqJyZZRSBH8fgdnZTQOxzHQss3OzFDr4kBab4dbpiuhjuc9rrpqRzgIvYYqeJ ht24COajBA3jemt1rc/MB6gwVwiadu/ScnTgo68u5/MENuRA5WbuFheWyCGmUVTEgc/X dclvG+ruM/ylwLeJmWVJUKNKj56Lko9aB8bue/1gXXXBrZfvGLORW6YWl7Q8q74OTR9h nSfJGdEF7G4a/YMPy56FRzvG6FBf5Twmy7OV0SHbNN+APomLBtzntZdMgjQaJs7oNm1V Xc6w== X-Gm-Message-State: AOJu0YxXalQdgeDpRDiIowkZNNV895hG1OdjM2zojE8ROsEvCx/Gb2zz EurokoZhR7ZUzcpLZKwBfW8R5fhuAFKDRlElD4ZhAAvjZxpFwTsmOdFw X-Gm-Gg: Acq92OFsQVah9daarYTegfOi+rLiY2fLpSLqGDOhLehSOEStzbi1/NfoeZjrIHQnvXf cs1ieYE3QS6uS8fJKydh8vnkrR3JaVeJ2Lbrjpst52kKJq+nKwSXOGWpedcHThB0C5nyJpqsf6N 9gqexoVhFhKgErtGij9ib3bvm/jOMOob/2upZbmzAW42SQFkJeFCHQthfiTUy//nwt6QjYzwoMU 4PjzF5XmP1ebj0zx689kcmeZc6F/orc5QefvEYzjmASnALgDKKGCA6me0t6LfQk9lEcydWcDd8X +/9WdlAlcOMz9Ja+G0yXv5EJDSoMkW8q2vBKL6qtT3h9ZKqsghciplSkmcwiJveFMm3y5nMKbPa W4eicSYhvFjaPJNeeAX63iPOzVqt0CgqIlU7VmOd0Y5v+iBP8laToHVSVFwgpjBtHczSq5csMK5 dPS60HesC/eN86g/+0bOepNpmc871Dgn+aJkkkkS9u1buCA8pNpiCfhe0xPO634EQrL0mmRuxxG Da6G6phV0B8 X-Received: by 2002:a05:600d:10:b0:489:e696:8362 with SMTP id 5b1f17b1804b1-48fe60d7882mr221269375e9.13.1779153782352; Mon, 18 May 2026 18:23:02 -0700 (PDT) Received: from node ([202.47.63.86]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45d9ec39ff1sm44255416f8f.10.2026.05.18.18.22.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 18:23:02 -0700 (PDT) From: Muhammad Bilal To: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org, oe-linux-nfc@lists.linux.dev, david+nfc@ixit.cz, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, stable@vger.kernel.org, Muhammad Bilal Subject: [PATCH net 1/2] nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers Date: Mon, 18 May 2026 21:19:36 -0400 Message-ID: <20260519011937.12903-2-meatuni001@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260519011937.12903-1-meatuni001@gmail.com> References: <20260519011937.12903-1-meatuni001@gmail.com> 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" nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain three related bugs in their TLV parsing loops: 1. 'offset' is declared u8 but tlv_array_len is u16. When TLV data advances offset past 255 it silently wraps to zero, causing infinite loops or double-processing of buffer data. 2. Before reading tlv[0] (type) and tlv[1] (length) there is no check that offset+2 <=3D tlv_array_len. A truncated TLV causes an OOB read of one byte past the buffer end. 3. After reading the length field, the value bytes are accessed without checking offset+2+length <=3D tlv_array_len. A crafted length=3D0xFF on a short buffer causes up to 255 bytes of OOB read past the buffer end. Both functions are reachable without authentication via nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes directly into nfc_llcp_parse_gb_tlv() with no additional validation. Fix all three issues by widening offset from u8 to u16 and adding bounds checks for both the TLV header and value field before each access. Fixes: 3df40eb3a2ea ("nfc: constify several pointers to u8, char and sk_buf= f") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Reviewed-by: Simon Horman --- net/nfc/llcp_commands.c | 28 ++++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c index 291f26fac..9162f8161 100644 --- a/net/nfc/llcp_commands.c +++ b/net/nfc/llcp_commands.c @@ -193,7 +193,8 @@ int nfc_llcp_parse_gb_tlv(struct nfc_llcp_local *local, const u8 *tlv_array, u16 tlv_array_len) { const u8 *tlv =3D tlv_array; - u8 type, length, offset =3D 0; + u8 type, length; + u16 offset =3D 0; =20 pr_debug("TLV array length %d\n", tlv_array_len); =20 @@ -201,9 +202,20 @@ int nfc_llcp_parse_gb_tlv(struct nfc_llcp_local *local, return -ENODEV; =20 while (offset < tlv_array_len) { + if (offset + 2 > tlv_array_len) { + pr_err("Truncated TLV header at offset %u\n", offset); + return -EINVAL; + } + type =3D tlv[0]; length =3D tlv[1]; =20 + if (offset + 2 + length > tlv_array_len) { + pr_err("TLV length %u overflows buffer at offset %u\n", + length, offset); + return -EINVAL; + } + pr_debug("type 0x%x length %d\n", type, length); =20 switch (type) { @@ -243,7 +255,8 @@ int nfc_llcp_parse_connection_tlv(struct nfc_llcp_sock = *sock, const u8 *tlv_array, u16 tlv_array_len) { const u8 *tlv =3D tlv_array; - u8 type, length, offset =3D 0; + u8 type, length; + u16 offset =3D 0; =20 pr_debug("TLV array length %d\n", tlv_array_len); =20 @@ -251,9 +264,20 @@ int nfc_llcp_parse_connection_tlv(struct nfc_llcp_sock= *sock, return -ENOTCONN; =20 while (offset < tlv_array_len) { + if (offset + 2 > tlv_array_len) { + pr_err("Truncated TLV header at offset %u\n", offset); + return -EINVAL; + } + type =3D tlv[0]; length =3D tlv[1]; =20 + if (offset + 2 + length > tlv_array_len) { + pr_err("TLV length %u overflows buffer at offset %u\n", + length, offset); + return -EINVAL; + } + pr_debug("type 0x%x length %d\n", type, length); =20 switch (type) { --=20 2.54.0 From nobody Mon May 25 04:33:50 2026 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 BD0C22DA75A for ; Tue, 19 May 2026 01:23:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779153791; cv=none; b=nrMYHKcB+8OVF9P9DM6QtV1h8M5fXwTat9gUNxBN4PUQ/i1doaDJVvYNBquXUcnGrz6Yon8afO/B0SwfaGvJjToVGDfPskmnQG7OWioEAh19xl8qSbMWgDZdVg9fpaO9I/UvXc3ZNP1b1Kk05163bgf/qAQCNymuyw9VbGDQUdQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779153791; c=relaxed/simple; bh=4vi/+e3xOXjw7xLTlUAikVPvzws2OAFyV8H8dZm6ePs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=b92XAPeJWkFnxb+pz2nLdY4dBiUPl6bj0rny3OprCKBF4WPWxlxm3g6PmEvJ1elyHv3Nlq3mlFVNCse5QQ17wEDGMr4izmsB/+cMhAYCuWVSlhA5oQw3mK9L7t2MtVsRLmJXKKK5VdGCeiHNZBGKllYQ6go2tQPy/lpU5hwf2dY= 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=p9ckhRst; arc=none smtp.client-ip=209.85.128.46 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="p9ckhRst" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-488af96f6b2so32115775e9.0 for ; Mon, 18 May 2026 18:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779153786; x=1779758586; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+T0H92Yt0pUbOJ2kFSqG2xMZBSz8hScaz9YpU8JwLL0=; b=p9ckhRst6+1XMFm9y23i0fqGCcPZa2CBPI+F3LOwSj3X39O4YF9hfCOVpYuc6toS9R HzrPtQBiVc6siUEPv+mPIJkCLO1vtMfjHvqjTW3OlO1X8k+uDfgpnq6doXqMn9zOdjQw hpxY+mSQT4q9T5Jc2/Fm7A+TwVBH3h2gavynDLcCbOCjMdnUt+SOR5H5o9mlPrzqR5bn efYvrothcrHbHhs8FdzuAs8wLka/4VaeLr5iMUPLP1eRiG2DbdvX7ii63y8HA/dJseRY I1IFIIQf7g9roaOD5z17tUhhQz5TnZcAtFxXLuO7ptm9bZt+OARyqbiDncqlbPmLgTNm Xgmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779153786; x=1779758586; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=+T0H92Yt0pUbOJ2kFSqG2xMZBSz8hScaz9YpU8JwLL0=; b=ltIR+5p31T9DlDYWEdyIrTHR/M5E+u71mw0VGlAH8uUj2Kxhqa/cyL7TGFVcbwifep q0Y3KC8TokkoY9f4d9JIVJfS3KaFaEgR5bSKznvZq1FO3T4pGU/pzn0RxQ7p+rlLfQET 8BrHbi1Y+LodenRL4qj2/S3PY10Xoy2sX2CyInD8pwlHDrS84M8BVbs4tbQsZWu/TOip Kfk939fSV0vp61DnaTdoZnaujZcUcWf/doYRgqgWo/OiocmpXjbzWQMonZ7ZcKifreTA IJZdSswNrhQ3xsOvM1M2gPdnh8mjm5PwmfDZ98KS9uL7vH/flCBRK9ImDl1uFHSAyVJl REig== X-Gm-Message-State: AOJu0YxypaxQmkQd3lb0vt3JiToqRHguXr/Qw/UMgbyomjr7zczcVUZM RHQsI8Jgi8nRlUKnzcookZfxDh6UpJl4jS5rOvWX9LGpHvDIDsxH2eHe X-Gm-Gg: Acq92OHM4TK4JkESmd3aqfQiTRWHHftf1DRQ15/mPdsOIxgjztZJTbrZl5oUD2j/QAk 8WAV51EZF5myZUCcevQBXzyB2QXdjzaPPciTOekZhe5eRwoRz7d8mCOQ6rFgmz5vUvjDoaTz9Jz gyV4FEtgaqK276Jzsq1VwYhZ0A0lC4jsjeHoSsGdbDN+Bx7qtIObWbSLd3jit37i2ZwGzV0tvm4 2Ndrzc3fkZW3srjVK6ra1SYviHlkF/zE7V+5nVZetJu5dU/DpTLcYowLrbSDyHPhkxjGA2RE9CL ECTDKLpO76/4TA8x4u0Ez5j3QsHj/ca/s9lF0MIv4kS+Nqak//2o22zFO1c8ehU7vQelu/vv4ZF bgOtdvundrj+CshKN9HnYUEQToZ7rp+XIx4G/rzq7xhI88eqHBFMFBMxj8gt4hadHcPFzhvdaTP 6pJLgit62RuIGCRZxWQj4Jvz2mG0m7TwTL6rj7cciTMy+rYYC2NiaAkmoo1/t7dpwcinxHX7LT3 w== X-Received: by 2002:a05:600d:10:b0:48f:e230:2a1b with SMTP id 5b1f17b1804b1-48fe6630137mr219596215e9.30.1779153785784; Mon, 18 May 2026 18:23:05 -0700 (PDT) Received: from node ([202.47.63.86]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45d9ec39ff1sm44255416f8f.10.2026.05.18.18.23.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 18:23:05 -0700 (PDT) From: Muhammad Bilal To: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org, oe-linux-nfc@lists.linux.dev, david+nfc@ixit.cz, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, stable@vger.kernel.org, Muhammad Bilal Subject: [PATCH net 2/2] nfc: llcp: add missing bounds checks in nfc_llcp_recv_snl() Date: Mon, 18 May 2026 21:19:37 -0400 Message-ID: <20260519011937.12903-3-meatuni001@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260519011937.12903-1-meatuni001@gmail.com> References: <20260519011937.12903-1-meatuni001@gmail.com> 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" nfc_llcp_recv_snl() processes remotely supplied SNL frames without validating TLV buffer boundaries before accessing header and value bytes, leading to three issues: 1. No bounds check before reading tlv[0] (type) and tlv[1] (length). When tlv_len - offset =3D=3D 1, reading tlv[1] accesses one byte past the end of the skb data. 2. For LLCP_TLV_SDREQ entries, tlv[2] (tid) and tlv[3+] (service_name) are read without checking offset+2+length <=3D tlv_len, allowing out-of-bounds reads beyond the skb data boundary. 3. service_name_len =3D length - 1 with length as u8 and service_name_len as size_t. When length =3D=3D 0, the subtraction yields SIZE_MAX on 64-bit kernels due to integer promotion. The computed SIZE_MAX value is propagated into nfc_llcp_sock_from_sn() as sn_len, bypassing the sn_len =3D=3D 0 guard and reaching subsequent comparison logic with an excessively large length argument. Fix all three issues by: - Adding a header bounds check before reading tlv[0]/tlv[1]. - Adding a value bounds check after reading length. - Rejecting SDREQ TLVs with length < 1 to prevent the SIZE_MAX underflow, while preserving length =3D=3D 1 as a valid case. - Rejecting SDRES TLVs with length < 2 since both tlv[2] and tlv[3] are required. Fixes: 19cfe5843e86 ("NFC: Initial SNL support") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal Reviewed-by: Simon Horman --- net/nfc/llcp_core.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c index db5bc6a87..da7c6377d 100644 --- a/net/nfc/llcp_core.c +++ b/net/nfc/llcp_core.c @@ -1300,12 +1300,28 @@ static void nfc_llcp_recv_snl(struct nfc_llcp_local= *local, sdres_tlvs_len =3D 0; =20 while (offset < tlv_len) { - type =3D tlv[0]; + if (offset + 2 > tlv_len) { + pr_err("Truncated TLV header at offset %u\n", offset); + goto exit; + } + + type =3D tlv[0]; length =3D tlv[1]; =20 + if (offset + 2 + length > tlv_len) { + pr_err("TLV length %u overflows buffer at offset %u\n", + length, offset); + goto exit; + } + switch (type) { case LLCP_TLV_SDREQ: - tid =3D tlv[2]; + if (length < 1) { + pr_err("SDREQ TLV length %u too short\n", length); + goto exit; + } + + tid =3D tlv[2]; service_name =3D (char *) &tlv[3]; service_name_len =3D length - 1; =20 @@ -1369,6 +1385,9 @@ static void nfc_llcp_recv_snl(struct nfc_llcp_local *= local, break; =20 case LLCP_TLV_SDRES: + if (length < 2) + break; + mutex_lock(&local->sdreq_lock); =20 pr_debug("LLCP_TLV_SDRES: searching tid %d\n", tlv[2]); --=20 2.54.0