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 9652DC433EF for ; Wed, 13 Apr 2022 19:27:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238345AbiDMT3v (ORCPT ); Wed, 13 Apr 2022 15:29:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238317AbiDMT3k (ORCPT ); Wed, 13 Apr 2022 15:29:40 -0400 Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 41A5B72E1D for ; Wed, 13 Apr 2022 12:27:17 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id n18so2792806plg.5 for ; Wed, 13 Apr 2022 12:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=ulZD6zNnI3E2tVgbP2ay2zB6j2x9YR9+l3/69/Ua3pA=; b=JLd5puMQf6492ML/dyNY6TKWLx7/9ZIuCpo4/MdsTOmTLArTtUAHSBUUksMMpNsbUg JKoMefN2Xhc4AQ40Oj/ty6rADytP+hgT6kUGvT/+DME34D1YFAeq1NkGOZwC2LD/nH7A UROiFTo0esSJrW/PMu2+jyzk+RilmC4re7wIb6Zj+9vn95TEcRuBhlxaxDMhY3k2FK9Z JF9sAJzfofpZ9TQMjkyuueU/pkYZfnd4WssWZzBXW8PLxVwodjar5qU85Jw0zbjCixvV UNSLduY+bWJgbHcYb6l5xShpVPyjY5c/TLwd1mNzgdN8nvRmYBPxs/1Sb65pSM4TrGJT 8Ahw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=ulZD6zNnI3E2tVgbP2ay2zB6j2x9YR9+l3/69/Ua3pA=; b=Dk6gT9e/NWuxbT3lb7PECFN4lnzx5RUJnh+avYSWvKuTiVgLrmBTf2Pp6B2l2moeIo r4fRh52ZPsGR6HjP7AFkkMWwp8vh5KFszIRWJI8astt36zdLoBFqP6eCKD1+ovtfqtUE 615Imp4WIMMcVVr5je4N6bBQptUnhH0E5yppxtO+XDbE9GvEeUcuMfqEegAESzudJURm MRKp/TlX8DTf9nxNBOME9i4soyx+43JqJiL4qSE1QYYUm1JJbloi5zzze5lG+gfJTHmD xwsL+69NSNZqzLYQO78AXAjdgwd2MSM8694xy/VQ7iqDiu2fHxUMm96inJNXArG/AjEK 7xxA== X-Gm-Message-State: AOAM530GTQ20lodR3annYOTOgdYzUNwJdGDrtRO1CIZp6wn6UnZ+RlsF AtFwjwwVzTBTdxoYsezQQhxwlA== X-Google-Smtp-Source: ABdhPJy2l1eOffJSFsfUgH2fvADP0aGuwJ8njCIdXBZ9pzOEzXCNNM+Oyp4lX76nDUJdDBeupVp7HA== X-Received: by 2002:a17:90a:454a:b0:1ca:91c7:df66 with SMTP id r10-20020a17090a454a00b001ca91c7df66mr288235pjm.186.1649878036766; Wed, 13 Apr 2022 12:27:16 -0700 (PDT) Received: from [192.168.254.17] ([50.39.160.154]) by smtp.gmail.com with ESMTPSA id v16-20020aa78090000000b0050583cb0adbsm18978259pff.196.2022.04.13.12.27.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Apr 2022 12:27:16 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2022 12:27:15 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] bpf: Fix KASAN use-after-free Read in compute_effective_progs Content-Language: en-US To: Andrii Nakryiko Cc: bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Networking , linux- stable , open list , syzbot+f264bffdfbd5614f3bb2@syzkaller.appspotmail.com References: <20220405170356.43128-1-tadeusz.struk@linaro.org> From: Tadeusz Struk In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/13/22 12:07, Andrii Nakryiko wrote: >> it would be ideal if detach would never fail, but it would require some kind of >> prealloc, on attach maybe? Another option would be to minimize the probability > We allocate new arrays in update_effective_progs() under assumption > that we might need to grow the array because we use > update_effective_progs() for attachment. But for detachment we know > that we definitely don't need to increase the size, we need to remove > existing element only, thus shrinking the size. > > Normally we'd reallocate the array to shrink it (and that's why we use > update_effective_progs() and allocate memory), but we can also have a > fallback path for detachment only to reuse existing effective arrays > and just shift all the elements to the right from the element that's > being removed. We'll leave NULL at the end, but that's much better > than error out. Subsequent attachment or detachment will attempt to > properly size and reallocate everything. > > So I think that should be the fix, if you'd be willing to work on it. That makes it much easier then. I will change it so that there is no alloc needed on the detach path. Thanks for the clarification. -- Thanks, Tadeusz