Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp901537pxb; Tue, 1 Feb 2022 12:47:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJwhHYdCs5c4kw4UDMfhVliY2rbGwImznV6VlZXh4aA6aYYc53WLrtQpUhVfPQjCwgZJrTBQ X-Received: by 2002:a63:d650:: with SMTP id d16mr19036423pgj.137.1643748456869; Tue, 01 Feb 2022 12:47:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643748456; cv=none; d=google.com; s=arc-20160816; b=RsAjfdDz/WBoEgqsF7tbPz0/GJrzuh2urTdDK6J5+TPJRY3am0zdS/jzxsp8glB11L Uk9AoDpUR9WLNg9gUq8pEB4qGmahx5uCXMB1fNucOkVR34KTQNL2Eo9ZcZwc7tMf3i5E k0+WJ4kbKXogB//OaNIo7VRNsryJ9yLk7sd7t1iDe0t43SRmQ4M4HAvI8YAMprZGTfXe G97Llyuy9JjM0W7pCKMajgGok+lUCCH7lF82tINqiiKl8ghvag0bb/KGGX59Hcc9FFTS HPXQrI74KZUs0kNN4FtUsa+U1UG/OX00KqRQC0Yp5yuiSp71RMO8ByPB3Iz+Okp7A9zD MjAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=317J+b5PpSz9x/w2XV3+0c4wYcSD3IlZCWiQWA5Ipxk=; b=dpXjg5PeAjbwfII0GPhswol9SMJavzqBoY1Fl2tNcoPS01PD1sl4D9JtO8flWB4CdQ bS36YM20/GkoTaqtkZ66rdgXrn6S05h2ZOGhTbeRlOIr4QffUadY2PepBbQPbPelBUKR Yk+gyWY6RvPPL4Qs6GwR8+scsxGKVrFddZW6PMNl9WPYJEXzK/2K/x6TnDsImZd59pc/ g7lSF/rQDfbv7GtyLEuQ5m+pgvNKaDE6qt6kN83O6p66xYlcKB5cXrcRDw+7YnRSTxT1 /pBsSwUfceueckaoSgl6DWDnEfvwSLnUMw3fMQ3pq48qd/a6+Myxw39qY1cELT5Nrwl3 ATQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=eI8S6HU4; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i4si15121724plb.295.2022.02.01.12.47.24; Tue, 01 Feb 2022 12:47:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=eI8S6HU4; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357564AbiAaSr5 (ORCPT + 99 others); Mon, 31 Jan 2022 13:47:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357946AbiAaSrx (ORCPT ); Mon, 31 Jan 2022 13:47:53 -0500 Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1D2DC06173B; Mon, 31 Jan 2022 10:47:37 -0800 (PST) Received: by mail-yb1-xb36.google.com with SMTP id j2so30170934ybu.0; Mon, 31 Jan 2022 10:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=317J+b5PpSz9x/w2XV3+0c4wYcSD3IlZCWiQWA5Ipxk=; b=eI8S6HU4hdhKI33oB2A77jQ5V2CxkG5J0sRSnPNQRR/LWUgBL44/AI5I8DKXpLtgAk U3PwrJjmLcA//CNKNXw6eUCi7hsWc7xfM6ZvWHSVzdZaO6AonSqjVCxah1otkOsB1fiV rc4oYNGl9hSbQmVH2LA72zjrYXbyTJmvzlodkB7nvGFsfK7ID1KN3R40xBYtv4Q30cVN 8jW0eKe7PAMFCwnGKwCzLODuvWtJ8VSf4lEsfr20OOCS2aXyETlK5OnePtwIAx62UmO0 MZzcycHt4kZ9O2mBjYD2cpDXOaARyCiN9A05TO0u8LqajMvO8LSm+nf4dhD7InRd7BwA x0aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=317J+b5PpSz9x/w2XV3+0c4wYcSD3IlZCWiQWA5Ipxk=; b=Z1Q6BXvMOG6KBvKe8WtbimM6NI8cDxI17S0HQ2picZPOtLqa2UXh1RHaIrcH+RGv8a mC/JCU6rpxnzE9deUiOrA8do6kApvOIxKTy/GH3O5Nr/nJYGWZRLakrv3LfmvcnfLgEk Qr+H2pqXCfLGCi0bRmP08sowq7p/g7hI3glhtc41VC5Gd+M9tH0K/pplP485hmgpavj+ GnP8BhBD4HMIAyHTAqbLawPtOiVaC2f89ABiM5MbGYSyll3P+fxhtGLasRH/RPSKu88t zFgBwd5icBliNuEeBORDpJsCj3eBeQqrCoLva95nzIwHn1IQ23Al6zeTx05TcLDSPetW UPcg== X-Gm-Message-State: AOAM530NnspZBtJ+hKJylxPucL3/1LixGiLgkvq+CqdBntm/iTXytrPV /LeDLvdnohrk6LB8feJzQJkqtnEBVhbXj9yxbQY= X-Received: by 2002:a25:50cf:: with SMTP id e198mr31706710ybb.398.1643654857132; Mon, 31 Jan 2022 10:47:37 -0800 (PST) MIME-Version: 1.0 References: <20220113150846.1570738-1-rad@semihalf.ocm> In-Reply-To: From: Luiz Augusto von Dentz Date: Mon, 31 Jan 2022 10:47:26 -0800 Message-ID: Subject: Re: [PATCH] Bluetooth: Fix skb allocation in mgmt_remote_name() To: =?UTF-8?Q?Rados=C5=82aw_Biernacki?= Cc: linux-bluetooth , Marcel Holtmann , CrosBT Upstreaming , Archie Pusaka , Miao-chen Chou , Jakub Kicinski , Johan Hedberg , Linux Kernel Mailing List , "open list:NETWORKING [GENERAL]" , upstream@semihalf.com, Angela Czubak , Marek Maslanka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Rados=C5=82aw, On Thu, Jan 13, 2022 at 2:23 PM Luiz Augusto von Dentz wrote: > > Hi Rados=C5=82aw, > > On Thu, Jan 13, 2022 at 2:07 PM Rados=C5=82aw Biernacki wrote: > > > > Hi Luiz, > > > > czw., 13 sty 2022 o 17:17 Luiz Augusto von Dentz > > napisa=C5=82(a): > > > > > > Hi Radoslaw, > > > > > > On Thu, Jan 13, 2022 at 7:09 AM Radoslaw Biernacki = wrote: > > > > > > > > From: Radoslaw Biernacki > > > > > > > > This patch fixes skb allocation, as lack of space for ev might push= skb > > > > tail beyond its end. > > > > Also introduce eir_precalc_len() that can be used instead of magic > > > > numbers for similar eir operations on skb. > > > > > > > > Fixes: cf1bce1de7eeb ("Bluetooth: mgmt: Make use of mgmt_send_event= _skb in MGMT_EV_DEVICE_FOUND") > > > > Signed-off-by: Angela Czubak > > > > Signed-off-by: Marek Maslanka > > > > Signed-off-by: Radoslaw Biernacki > > > > --- > > > > net/bluetooth/eir.h | 5 +++++ > > > > net/bluetooth/mgmt.c | 12 ++++-------- > > > > 2 files changed, 9 insertions(+), 8 deletions(-) > > > > > > > > diff --git a/net/bluetooth/eir.h b/net/bluetooth/eir.h > > > > index 05e2e917fc25..e5876751f07e 100644 > > > > --- a/net/bluetooth/eir.h > > > > +++ b/net/bluetooth/eir.h > > > > @@ -15,6 +15,11 @@ u8 eir_create_scan_rsp(struct hci_dev *hdev, u8 = instance, u8 *ptr); > > > > u8 eir_append_local_name(struct hci_dev *hdev, u8 *eir, u8 ad_len)= ; > > > > u8 eir_append_appearance(struct hci_dev *hdev, u8 *ptr, u8 ad_len)= ; > > > > > > > > +static inline u16 eir_precalc_len(u8 data_len) > > > > +{ > > > > + return sizeof(u8) * 2 + data_len; > > > > +} > > > > + > > > > static inline u16 eir_append_data(u8 *eir, u16 eir_len, u8 type, > > > > u8 *data, u8 data_len) > > > > { > > > > diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c > > > > index 37087cf7dc5a..d517fd847730 100644 > > > > --- a/net/bluetooth/mgmt.c > > > > +++ b/net/bluetooth/mgmt.c > > > > @@ -9680,13 +9680,11 @@ void mgmt_remote_name(struct hci_dev *hdev,= bdaddr_t *bdaddr, u8 link_type, > > > > { > > > > struct sk_buff *skb; > > > > struct mgmt_ev_device_found *ev; > > > > - u16 eir_len; > > > > - u32 flags; > > > > + u16 eir_len =3D 0; > > > > + u32 flags =3D 0; > > > > > > > > - if (name_len) > > > > - skb =3D mgmt_alloc_skb(hdev, MGMT_EV_DEVICE_FOUND, = 2 + name_len); > > > > - else > > > > - skb =3D mgmt_alloc_skb(hdev, MGMT_EV_DEVICE_FOUND, = 0); > > > > + skb =3D mgmt_alloc_skb(hdev, MGMT_EV_DEVICE_FOUND, > > > > + sizeof(*ev) + (name ? eir_precalc_len(= name_len) : 0)); > > > > > > Looks like mgmt_device_connected also has a similar problem. > > > > Yes, I was planning to send a patch to this one though it will not be a= s slick. > > It would be nice to have a helper which will call skb_put() and add > > eir data at once. > > Basically skb operation in pair to, what eir_append_data() does with > > help of eir_len but without awkwardness when passing return value to > > skb_put() (as it returns offset not size). > > Hmm, that might be a good idea indeed something like eir_append_skb, > if only we could grow the skb with skb_put directly that would > eliminate the problem with having to reserve enough space for the > worse case. > > > I will send V2 with two patches. I hope they will align with your > > original goal of eliminating the necessity of intermediary buffers at > > some point in future. Are you still planning to send the v2? > > > > > > > ev =3D skb_put(skb, sizeof(*ev)); > > > > bacpy(&ev->addr.bdaddr, bdaddr); > > > > @@ -9696,10 +9694,8 @@ void mgmt_remote_name(struct hci_dev *hdev, = bdaddr_t *bdaddr, u8 link_type, > > > > if (name) { > > > > eir_len =3D eir_append_data(ev->eir, 0, EIR_NAME_CO= MPLETE, name, > > > > name_len); > > > > - flags =3D 0; > > > > skb_put(skb, eir_len); > > > > } else { > > > > - eir_len =3D 0; > > > > flags =3D MGMT_DEV_FOUND_NAME_REQUEST_FAILED; > > > > } > > > > > > These changes would leave flags and eir_len uninitialized. > > > > Both are initialized to 0 by this patch. > > Sorry, I must be blind that I didn't see you had changed that to be > initialized in their declaration. > > > > > > > > -- > > > > 2.34.1.703.g22d0c6ccf7-goog > > > > > > > > > > > > > -- > > > Luiz Augusto von Dentz > > > > -- > Luiz Augusto von Dentz --=20 Luiz Augusto von Dentz