From nobody Mon Jun 8 05:26:22 2026 Received: from mail-dl1-f42.google.com (mail-dl1-f42.google.com [74.125.82.42]) (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 834702DF128 for ; Mon, 1 Jun 2026 16:22:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780330970; cv=none; b=meexrd/ujbjEQx/Gx6mYFhGrwx3vQuwZIGAmKP7z4Aui+UdJ5HM/3zs8aLeAtbV/kZpSyhfjX8eia7Gxn9tfQSXAqINKZSV2MbN81hfWtl9SjZeZwqC9DPEoVnWYT6ZbR8qiZbROsHrxUV3iaJePoE/WNxL9NsOVGLnIdbDF5UE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780330970; c=relaxed/simple; bh=XbDa7ahvkbouj4nXflmBjHzwiZb+OcXPwS3KDXfIhLI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=RRXRq4bdtVXeyIowC61eJpGfpohvA6PgBfxDcTCFJ7OS3ZR4gz5iQWHTZUeVT/UH5/5oORezMPydJOqd4AOteVnE4pmhyS+ZPfGiu9xwa5O5o4m9NofRexDYndRk8SE4beKLAr/eaUrshNLoqnDcfv/sWptMjhVqukrLiouwZpY= 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=Vpb38Ga5; arc=none smtp.client-ip=74.125.82.42 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="Vpb38Ga5" Received: by mail-dl1-f42.google.com with SMTP id a92af1059eb24-1370417c01cso9760955c88.1 for ; Mon, 01 Jun 2026 09:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780330968; x=1780935768; 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=2jX84Zk+X2wna8QCsEP2HWNpN4PTnI4XWkcFVPYbSFY=; b=Vpb38Ga59+ox5SEAcGcWf6IMHUJ/r7/e3QjfbF9tJ8+rceSyBeDs2zeBx1ouMJgmp6 E2gFEKI/wHo9fTbt0ch9zsQeFN2UbUevZSjVDNbc8+jkTVuXMohi0eJOyiXbBHStZQL2 sZL1xxz+y1SV1voohcq5q3ebWNsHudyH6hwDEpI0fMgTwBVtrsN4mRVV7rh9Gf+5CTWp w/yhQvNd55L71ZDUvtjzOU6LNvj23pm8Iv5teRZgIwQWpUcrg3bAmn1NlSnLMKZwJvq0 V+Y+6FRSxWKBs+wxG32bqo+D1PweQbcKPA0qOLOsIKtMioVCbvM1yaKCdE8FyBBuFDVn BN4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780330968; x=1780935768; 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=2jX84Zk+X2wna8QCsEP2HWNpN4PTnI4XWkcFVPYbSFY=; b=g+wUqXnrujsX0QelRpHzUBKvhVFYZkWAyYOpZDnE5aWLkkja+7ZoVhsmbfee4uKLz5 bsMU+xscsKD6iKqCzf0vc8VA4pUndHb5egFIlGwj3MQbve1GR4bPzpI0lAbonPCwJeEf +Dj2MC5m5ZJql6DOCzUoGHVygmiy+ekCrG19f9IKVnOWk4kL6msDzPliShlHfhWs8c2d A5G4mx3XNTT8XWHK/hgROYmDOexgKzYNUUTDxrMXLY4P9gQvU2KZI4fxrgkdT4xNqa2D qPNthdN84IdODglAZBwGC6xPUAhdxJiMYtaE0fHfg/672EoTbB9UdITl1X0DhdDguxNS wm3A== X-Forwarded-Encrypted: i=1; AFNElJ9XtmucbzPOXfqNrbM/Vi1sF2WRjpoShVB3CDdPaNLmseBtlbLqUyudEQiQA4uQp9SdhYfIVpL490j0KcE=@vger.kernel.org X-Gm-Message-State: AOJu0Yx1h1gW3ZouxZRGKgH/ZLROUkd9etSnNRO1DxyfApR4FcSpqUe5 t8QAe3t/ZbIW0EVwWyuhJ1+G87X6fAni72RYBBRU79skkv5rQTvsRMhoLO6AUQuDQUs= X-Gm-Gg: Acq92OFv+uOVNkIXpr/+GuYnFp/vy9/JZFGkuHdSYwDXfkWNI0gVDzeRsGYgp0oxvYW nuyagkMghL56fUgx8/pBEmsRzDkk19MP7BRnFuTq0c2K4m07vB0JS5m/ifnAPkuwpTRpUirkAZC sCZGHELmGCBdqYmSPFsaV86nOq2R4NP9Kuv91b9JjGBRTb0DBW27HeXQP5Vidkzao/SZu+d+/XK NJ6NdebfiLNWVt+AMWavi2sX6VBEhAZc9KHSudFCeeosuDLdB/j9K5J/aWpV3XiXZHvtcV9dixe +CwFSq9NJnMwJgHaNsr0ztEfDq+FGttLHdDJzSwubP7Cx0l8251u1KOz0OB+OQBGnjvu5qhCEfK SLaiI9F4SE6sJPCD4YutA16CyLt4P+bflc76UTrlCXEt+/1iDpLMBw1A1YGoGqFK/ijLrd6TYCD n+cNJxAgY2Hgq0d1QqSd+5mj3MUwDR0ZbGygoZ4ButqPQnVprDHkasZhxbejeZ3GcuAFk/D60= X-Received: by 2002:a05:7022:e24:b0:134:df4a:2821 with SMTP id a92af1059eb24-137d42a2f43mr5506484c88.40.1780330967474; Mon, 01 Jun 2026 09:22:47 -0700 (PDT) Received: from fx.tailc0aff1.ts.net ([206.206.192.132]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-137b2d04287sm9134597c88.0.2026.06.01.09.22.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2026 09:22:46 -0700 (PDT) From: Xiang Mei X-Google-Original-From: Xiang Mei To: linux-bluetooth@vger.kernel.org Cc: Marcel Holtmann , Luiz Augusto von Dentz , Weiming Shi , linux-kernel@vger.kernel.org, Xiang Mei Subject: [PATCH bluetooth] Bluetooth: eir: Fix stack OOB write in eir_create_adv_data() Date: Mon, 1 Jun 2026 09:22:04 -0700 Message-ID: <20260601162203.1253918-2-xmei5@asu.edu> X-Mailer: git-send-email 2.43.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" From: Weiming Shi eir_create_adv_data() builds the advertising data into a fixed-size buffer of "size" bytes (31 for the legacy path in hci_set_adv_data_sync()). It may prepend a 3-byte "Flags" AD structure, but the per-instance advertising data is then copied without checking that it still fits: skip_flags: if (adv) { memcpy(ptr, adv->adv_data, adv->adv_data_len); The "Flags" structure is added whenever BR/EDR is disabled (LE_AD_NO_BREDR), which is the normal state for an LE-only controller. However, the mgmt length validator tlv_data_max_len() only reserves those 3 bytes when the user-supplied adv_flags carries a managed-flags bit (DISCOV / LIMITED_DISCOV / MANAGED_FLAGS). Adding an instance with flags =3D=3D 0 reserves nothing, so adv_data_len is accepted up to the full buffer size. At advertise time the 3 flag bytes are still prepended, and the subsequent memcpy() writes 3 + adv_data_len bytes into the size-byte buffer, overflowing it by the attacker-controlled tail of adv_data: BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir= .c:302) Write of size 31 at addr ffff88800b7e7bac by task kworker/u9:0/51 Workqueue: hci0 hci_cmd_sync_work __asan_memcpy (mm/kasan/shadow.c:106) eir_create_adv_data (net/bluetooth/eir.c:302) hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1689) hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:2015) hci_cmd_sync_work (net/bluetooth/hci_sync.c:332) This frame has 1 object: [32, 64) 'cp' The inconsistency dates back to when the managed "Flags" field was first added to the Add Advertising path: the prepended LE_AD_NO_BREDR flag does not depend on the user-supplied adv_flags, but tlv_data_is_valid() only reserved room when MGMT_ADV_FLAG_DISCOV was set. Commit 47c03902269a ("Bluetooth: eir: Fix possible crashes on eir_create_adv_data") later added the "size" argument and bounds-checked the "Flags" and "Tx Power" AD structures, but left this copy unguarded. Guard it the same way so the data is only copied when it fits. The bug is reachable by a local user with CAP_NET_ADMIN that owns an LE-only controller using the legacy advertising path. Fixes: b44133ff03be ("Bluetooth: Support the "discoverable" adv flag") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi --- net/bluetooth/eir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/bluetooth/eir.c b/net/bluetooth/eir.c index 3f72111ba651..e574f8f61e16 100644 --- a/net/bluetooth/eir.c +++ b/net/bluetooth/eir.c @@ -297,7 +297,7 @@ u8 eir_create_adv_data(struct hci_dev *hdev, u8 instanc= e, u8 *ptr, u8 size) } =20 skip_flags: - if (adv) { + if (adv && ad_len + adv->adv_data_len <=3D size) { memcpy(ptr, adv->adv_data, adv->adv_data_len); ad_len +=3D adv->adv_data_len; ptr +=3D adv->adv_data_len; --=20 2.43.0