From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A89A3C43334 for ; Sun, 5 Jun 2022 16:35:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346158AbiFEQfO (ORCPT ); Sun, 5 Jun 2022 12:35:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48018 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351253AbiFEQe5 (ORCPT ); Sun, 5 Jun 2022 12:34:57 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D34294D274 for ; Sun, 5 Jun 2022 09:34:56 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id bg6so4961149ejb.0 for ; Sun, 05 Jun 2022 09:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jdIVKFSk2eIbeHqEWdMi4/8HFEkUDh1Z4gYM7GW4sa0=; b=QiWi8O0uBmOcDTjvLLtS7RJP75oD8QAMzCNIR6xgGGo8LMbdoFvr7/kDyWQLXQ55uU K+AiabjxiAwoJ89j+dYMVQGZfwFWy22kGZQb4YLQYDlhkEVn7n7dby8AaXnObgdo72fN GZwRjklJ0BMY1TqUhjMmtDoTtyK0M+bX7NU3c= 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; bh=jdIVKFSk2eIbeHqEWdMi4/8HFEkUDh1Z4gYM7GW4sa0=; b=cNIdgGyLcQnNdxbnagOpBwjInSlUFKWVYRGMpp98pOcuPtOKiAU4E/qyaC3y1whcHs Y9WHB9+l8w/8FCIvM/1IPBnafeXl/X4dAO+9Gx8TJTF2opL7sBGaqpp3schYocUI+OSa +aB+MmSYKxDsNGocs6UCI7hsspOK5RVih+tGGuRCp4z3NNlHR6NMS9GJR6lx3i6lgSv6 PPg4kUfjHiGH37YN2NaT0hV5Yw9gxPypNGRNj7I+A8WZYOyoc8YzvYuZFPhnIu20Rs49 zCcVJ3Ai8n9ctrs4Vsxpz+1lI85D5XdGD/tSmpB12vr3okt6ksqScdf0VAL98NpssGcw 105Q== X-Gm-Message-State: AOAM533qSbRSoOlMeGRViDK8kkV45o4p08Zs6dQNgz1lFBjcWkCg1mLC Otc3S8MeJOwbqCDg03fjcPHEJp7ZPY+GH30Y X-Google-Smtp-Source: ABdhPJyXnfKJdz+KrWN8KX/InK4YHUQCnpTr0vt8jIgjbg4O5L1Yq9DREXiJajwqTlKuwvnbvYFQOA== X-Received: by 2002:a17:906:19d8:b0:70b:2ef8:e563 with SMTP id h24-20020a17090619d800b0070b2ef8e563mr15976795ejd.536.1654446895147; Sun, 05 Jun 2022 09:34:55 -0700 (PDT) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com. [209.85.221.46]) by smtp.gmail.com with ESMTPSA id 4-20020a170906310400b00705976bcd01sm5322126ejx.206.2022.06.05.09.34.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Jun 2022 09:34:53 -0700 (PDT) Received: by mail-wr1-f46.google.com with SMTP id x17so16755103wrg.6 for ; Sun, 05 Jun 2022 09:34:53 -0700 (PDT) X-Received: by 2002:a05:6000:16c4:b0:20f:cd5d:4797 with SMTP id h4-20020a05600016c400b0020fcd5d4797mr17796010wrf.193.1654446893075; Sun, 05 Jun 2022 09:34:53 -0700 (PDT) MIME-Version: 1.0 References: <20220605162537.1604762-1-yury.norov@gmail.com> In-Reply-To: <20220605162537.1604762-1-yury.norov@gmail.com> From: Linus Torvalds Date: Sun, 5 Jun 2022 09:34:37 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] net/bluetooth: fix erroneous use of bitmap_from_u64() To: Yury Norov Cc: Marcel Holtmann , Johan Hedberg , Luiz Augusto von Dentz , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Guo Ren , linux-bluetooth , Netdev , Linux Kernel Mailing List , linux-csky@vger.kernel.org, Sudip Mukherjee , Alexander Gordeev , Andy Shevchenko , Christian Borntraeger , Claudio Imbrenda , David Hildenbrand , Heiko Carstens , Janosch Frank , Rasmus Villemoes , Sven Schnelle , Vasily Gorbik Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jun 5, 2022 at 9:25 AM Yury Norov wrote: > > The commit 0a97953fd221 ("lib: add bitmap_{from,to}_arr64") changed > implementation of bitmap_from_u64(), so that it doesn't typecast > argument to u64, and actually dereferences memory. Gaah. That code shouldn't use DECLARE_BITMAP() at all, it should just use struct bdaddr_list_with_flags { .. unsigned long flags; }; and then use '&br_params->flags' when it nneds the actual atomic 'set_bit()' things and friends, and then when it copies the flags around it should just use 'flags' as an integer value. The bitmap functions are literally defined to work as "bit N in a set of 'unsigned long'" exactly so that you can do that mixing of values and bit operations, and not have to worry about insane architectures that do big-endian bit ordering or things like that. Using a 'bitmap' as if it's some bigger or potentially variable-sized thing for this kind of flags usage is crazy, when the code already does /* Make sure number of flags doesn't exceed sizeof(current_flags) */ static_assert(__HCI_CONN_NUM_FLAGS < 32); because other parts are limited to 32 bits. I wonder how painful it would be to just fix that odd type mistake. Linus