From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) (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 C31E433A033 for ; Tue, 2 Jun 2026 16:14:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780416900; cv=none; b=Opqlz449sqsVXxM3LVj0UgtPRDgX00P9qbfyPencLpnS08BtA/JPPXpNv56TJQPtBtxeB16J1NQ/rqudys4OFaVljXKVGOmBnor1Q4y/HgQJJzOLo2F4Kb/fJiO67xoRK8nLq8Dp4/0cF0qLNzESXy4wkbBva4tZqLyucB5Zeig= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780416900; c=relaxed/simple; bh=lL1zHR2IFb+gPf8hWQ++nvFThHcVEYvzC0CHBXvFRq0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TxWGv5m8jEB+2p6FOvamrIqy9J+hDnvnkg1f82V7YqEiaA5n9kXFGfya/wfsCFqZ/zkF8gERBA08jaRPScW74n/vNfgKKdsRPU1RU2KfZN/Fzc9GuSqt3nZn1lf0ajAoa/TxFtprOd5/yocuDba9YwZ51Lu+q4Xrb/3qOju+wO4= 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=KI6jObQh; arc=none smtp.client-ip=209.85.210.180 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="KI6jObQh" Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-842319576d5so1499204b3a.1 for ; Tue, 02 Jun 2026 09:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780416898; x=1781021698; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=xGmhscCRZ5kqGIMs9rnifmd/lKYyPDpcb87Wiw54uy4=; b=KI6jObQhtoGUhJrZlFmliEFHcAnEPxgHTJulk+kEC7DUl1sor5QRNxafszVRQ7kHXJ r+/nwQyT87TdYCMSOllNjysPidn1kjLckJmDzgOWn2giMoFpXlyTfuFUuECgCDYGDy4t 3ai/X+kU2UaiTRKbkneG9KeBtXriKR+9QLHEbzwD9Ryx0o0XZbqY6a+x6BHi5AAjYheA R5RY0okCkBMOBFYRpBkQXWzWjhGH4uUSPdISNU6KrvJfbTzZhsahibK/AeT4+mU+NN2Q R8iKxAjO3Vx5pcJtLN5LbCuKDZylnnbE8su/dBa4rpOJVC4J63w89l1wImtASHh5L2xp WXJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780416898; x=1781021698; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xGmhscCRZ5kqGIMs9rnifmd/lKYyPDpcb87Wiw54uy4=; b=if3hHM7d44Ut4x71Lmy3NrWAyWztL0C2iagCY1w8lDjrGzw39Jg/zcglzVDx6uBQeV Gkw/PsCCNfMJTvXp2pkKz/6WljDPbjdce1j9nQ9PPJUJWZJyhetd6gsvNPbnsEFYu2Rg fhhb6GArHRrN14LaSGe83LQpMYh7rGPpR2C4qvKYR8OmgYj+dgSCVAUrK3o3oN2Med3B bCw5tWAeyF2P4UpfDvkjxPCEMQhaOXK7rrp+3rEJIA/Cc0tFL/Zl9wWBytF1akCD2Hpp bM08XBmklGNxD1aHifdWTq0R55Hk4wBJPc8iwSqxyaEfM9wVOVQ3PqtdQRjOJHMcB2ku sJBA== X-Forwarded-Encrypted: i=1; AFNElJ+mY9kJuVz+kHCnEYV0xGmE5sd5+Ia0tkeKR9XaBRXkYr/MivacpLRf8N+M45eoFA4Fuw+wUpF/IqwYVjU=@vger.kernel.org X-Gm-Message-State: AOJu0Yym+33Dxfv5yHHlPloamJZIb1m3da1DjiH7A8HEALsJSqWzi/CN l/lFqJ5iOKbcaGkzE4Beusu2iFICBZOGrDpFXjXbYSPC/ZzK3pUC/kWZ X-Gm-Gg: Acq92OHHoqZkaY1zoskIqDqYy1BEp6tlER4HzdrPAMJT1ZDft2rHwFYW/GAQ5YqYi56 1YHeIkSk0PkQUgUVcy3E9eOuS0DZQS4rN0dSopuSAtCUr52yT1kSYWIBRYAOU4TBuZ8Y2t4TtNy Tpq2tD6os4scsABFD/wjBOYuw2tAW1EBQQ2JyDWBFmNyidGnC7EP8y6mlmDRemnmouxE0Wx2G2M y1/w6mKRqzby0KBAVngqi63t29F/03tCfU9vq0/aTAgxdtZXHL/QwneGxz6/4OkgWhHueTExKpP NMmryuD9BTEdmbXeDU33W0xFVl0bvtObppr7ohOGKs8IBC9/jH8aBF1E32Jqb9y/SzGzNPTMdTZ vEsqzTl9gVDAn+kIrmySC09NGxuNp2Hi2Se2L1ySRlmbkALGH2hnrPlztiZtTFTaLA9mhRHOf9q 1qWtBy9GZ0+1RSkt+uiwd0DRfnjbiLcpdF6EhhNSk/e1+Nl4it1Ciu5IRDWEjbLQ== X-Received: by 2002:a05:6a00:400d:b0:842:6004:3fd4 with SMTP id d2e1a72fcca58-8428310e867mr200503b3a.24.1780416897881; Tue, 02 Jun 2026 09:14:57 -0700 (PDT) Received: from Air.local ([198.176.50.157]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8428235006dsm277081b3a.13.2026.06.02.09.14.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 09:14:57 -0700 (PDT) Date: Wed, 3 Jun 2026 00:14:51 +0800 From: Weiming Shi To: Luiz Augusto von Dentz Cc: linux-bluetooth@vger.kernel.org, Marcel Holtmann , linux-kernel@vger.kernel.org, Xiang Mei Subject: Re: [PATCH bluetooth] Bluetooth: eir: Fix stack OOB write in eir_create_adv_data() Message-ID: References: <20260601162203.1253918-2-xmei5@asu.edu> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On 26-06-01 13:38, Luiz Augusto von Dentz wrote: > Hi Xiang, > > On Mon, Jun 1, 2026 at 12:22 PM Xiang Mei wrote: > > > > 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 == 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' > > Add the btmon trace of the MGMT command when this is triggered, and > explaing how the advertisement was created, as with bluetoothd? > > > 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 instance, u8 *ptr, u8 size) > > } > > > > skip_flags: > > - if (adv) { > > + if (adv && ad_len + adv->adv_data_len <= size) { > > So we have 2 options: 1) Don't add flags if there is no space, or 2) > Don't add the user provided data. We should probably choose option 1, > not option 2 since option 2 probably means the advertisement is > useless. > > > memcpy(ptr, adv->adv_data, adv->adv_data_len); > > ad_len += adv->adv_data_len; > > ptr += adv->adv_data_len; > > -- > > 2.43.0 > > > > > -- > Luiz Augusto von Dentz Thanks. Agreed on option 1. I'll send v2 implementing that shortly.