Received: by 2002:a05:7412:f690:b0:e2:908c:2ebd with SMTP id ej16csp1096469rdb; Fri, 20 Oct 2023 08:19:47 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEIik/gzzzlMlQiWkvfrBMxJyK6GTAmQWn+J92Tek5J1rsIgF2Pj9oFJ1y8kHt4u6OrZyNj X-Received: by 2002:a05:6a20:12d4:b0:174:52b7:f63 with SMTP id v20-20020a056a2012d400b0017452b70f63mr2486050pzg.26.1697815187560; Fri, 20 Oct 2023 08:19:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697815187; cv=none; d=google.com; s=arc-20160816; b=M/yI2e2BDFR3CpE+kehzfvMHZtqfvEIe5scEouDlnU/07YOCMbenR6O51a6qT0jTiI MlObqcqx6UbR68uIrvV0HXX5r722kW1WvoAYUkdkeOZb0288+9EgFNaA3YRk1sGIReWw s9AGoYLh36DGb5lJn4JGnANM0CzNljLjegqeAog/SeADIvfkOH6i/d38ufO+Qv/ifkXP RDXsCNWXD0Yvn6+AUUkBXR7H7ry/qS049fdaQz/rLiFXpEWMpRP7R8AfdHu1LFwxlpIu 9MajKJ52naWDQovCYHBYZzuKz8S+WcBGHqKrhZpDWhU5i7kB5bJ/3vKK0XvFxhkj1OAa MknQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=yXhmtsd7v35VsKDTvdSZ2foO72l9HxK/7NMvbj357Oc=; fh=FE+flKamKCt2Tib1q1mT7xnzB2HgVsYNVMZt24gYlDs=; b=A3qPar50iXoofBXm0NLVbEUfQSXsrpWGyVqzHDWeTt66eFvYuaNCeN4yycd9znimqF tld6TALZd1vwW7RPZiDAwc8Hex3z1VKASg3G1qCas7dAyd+rTt14OAEqs3G4TejEBB+L mpT4gqaMxUL8WSmv4mJOdU3j3bDkg20aS9AoWaHkWvDjQu+l+pQSGp13LbBvItlsRYQY YHLlfrpDdlyQeNsQGC2QZMRiMqGKV9QkcrGS+rJu6qeDoSZLk5gWgjWGofArKgQnRVgJ eOeFrwHI9f2rmUXKmO5RUi8VI8PJK1ZBFW2DhW9pPJJgKBAkAPWJQ7EgqnaJJDm7mAAb 9w+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance.com header.s=google header.b=QEltRJ17; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=bytedance.com Return-Path: Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id t20-20020a63b254000000b005a9b2800a0bsi1998864pgo.344.2023.10.20.08.19.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Oct 2023 08:19:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance.com header.s=google header.b=QEltRJ17; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=bytedance.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 2923382D256F; Fri, 20 Oct 2023 08:19:45 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377676AbjJTPT3 (ORCPT + 99 others); Fri, 20 Oct 2023 11:19:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377620AbjJTPT2 (ORCPT ); Fri, 20 Oct 2023 11:19:28 -0400 Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29645D55 for ; Fri, 20 Oct 2023 08:19:26 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-5b852632be4so29793a12.1 for ; Fri, 20 Oct 2023 08:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1697815165; x=1698419965; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=yXhmtsd7v35VsKDTvdSZ2foO72l9HxK/7NMvbj357Oc=; b=QEltRJ17lV9C8l8ZncfVwjXjdgfQIWCXoLLpXZfXy2mCRDe8LJjbc0yDWG14/9xwPf g/9CIXVd0tzFiHyWUJZKCwa8FbXgy4nckO0Fg09Lfuf6OGK2QCSA7gOdHZiyOgDHEeHx aANid33mJ/4vQyoxA7IrskLpOsN8MKshHgkRWWrd5tilG6ZAuVAjkM8pVu7h2sCuscdO f16UnCPThQoWcQf8gtYsTq8Z0LOZMik2kiueUZICOzmVOoJXzWWCPpBivEk70YSsS2hn lu7JOjTc4RdYvzoX7wpBlu9B7nkXgcQJWlQ6o0MCi96Fl8sNtMWgXwOOWCyRICyIERId MaTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697815165; x=1698419965; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yXhmtsd7v35VsKDTvdSZ2foO72l9HxK/7NMvbj357Oc=; b=kk6UnjgyTDNLuO4qn73WiABJ0BIy1VWQRGEzCf35YDGGQygkyjH85DcohZnstAiyh1 kk+yK0thfuUTpfpWAj3lX9er37EMUqTtZ1fVF3DYqssBdNEUslwMoHROXQE+fK8Ly3Sd 9Jl4lLYUq0fs3XalVp3sfiVipUSf+uM1h37GB4RgMTwBJq8lrhi7wkZF2H9Hqo00NzIQ 7giY4GEMKouay1bMnKMAwTlWUVcwdxV46YwTfVepIH8EUtPtX1rIpVcViv4GH5IlufMe x7bD9a5i/F18F7llRpQ7lSKf2D5NITbjkfGK7h6zYSOZtYkrljs+irC3zo5Y61HvokxS CUiQ== X-Gm-Message-State: AOJu0YwhxJWk3Nf2El824sG9OMRGUdIo4KJmDe4wnQ2VAYiVm2uQ+XM3 peb3Gq4BeajqisYg7PnO1X8IOA== X-Received: by 2002:a05:6a21:7881:b0:16e:26fd:7c02 with SMTP id bf1-20020a056a21788100b0016e26fd7c02mr2448569pzc.2.1697815165551; Fri, 20 Oct 2023 08:19:25 -0700 (PDT) Received: from [10.4.4.198] ([139.177.225.251]) by smtp.gmail.com with ESMTPSA id 25-20020a17090a031900b0026b3a86b0d5sm1732974pje.33.2023.10.20.08.19.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Oct 2023 08:19:24 -0700 (PDT) Message-ID: <58a42dfb-38f8-4935-ac4d-4ec34c3c9504@bytedance.com> Date: Fri, 20 Oct 2023 23:19:20 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: KASAN: slab-use-after-free Read in radix_tree_lookup in&after Linux Kernel 6.4-rc6 Content-Language: en-US To: Matthew Wilcox Cc: Petr Mladek , Zhang Zhiyu , linux-kernel@vger.kernel.org, Andrew Morton , secalert@redhat.com References: From: Qi Zheng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Fri, 20 Oct 2023 08:19:45 -0700 (PDT) Hi Matthew, On 2023/10/20 22:58, Matthew Wilcox wrote: > On Fri, Oct 20, 2023 at 09:51:18PM +0800, Qi Zheng wrote: >> Hi all, >> >> On 2023/10/20 20:34, Matthew Wilcox wrote: >>> On Fri, Oct 20, 2023 at 10:26:31AM +0200, Petr Mladek wrote: >>>> Adding Matthew into Cc in the hope that he is still familiar with the >>>> code. Also adding Andrew who accepts patches. >>> >>> oh joy. i love dealing with cves. >>> >>>>>> I agree, this issue looks to be in kernel-core radix tree code in ./lib/radix-tree.c in two of any places. >>> >>> the radix tree code is the victim here. maybe also the perpetrator, but >>> it's rather hard to say. >>> >>> shrink_slab_memcg() >>> down_read_trylock(&shrinker_rwsem) >>> shrinker = idr_find(&shrinker_idr, i); >>> >>> i assume is the path to this bug. the reporter didn't run the >>> stacktrace through scripts/decode_stacktrace.sh so it's less useful than >>> we might want. >>> >>> prealloc_memcg_shrinker() calls idr_alloc and idr_remove under >>> shrinker_rwsem in write mode, so that should be fine. >>> >>> unregister_memcg_shrinker() calls idr_remove after asserting &shrinker_rwsem >>> is held (although not asserting that it's held for write ... hmm ... but >>> both callers appear to hold it for write anyway) >>> >>> so i don't see why we'd get a UAF here. >>> >>> anyway, adding Qi Zheng to the cc since they're responsible for the >>> shrinker code. >> >> Thanks for CC'ing me, I'd be happy to troubleshoot any issues that may >> be shrinker related. >> >> Between v6.4-rc1 and v6.4 versions, we briefly implemented lockless slab >> shrink using the SRCU method. In these versions, we call idr_alloc and >> idr_remove under shrinker_mutex, and idr_find under srcu_read_lock. >> >> These are all legitimate uses of the IDR APIs and the shrinker_idr >> will never be destroyed, so at a quick glance I didn't see why it would >> cause UAF here. > > I'm not an expert on how all the RCU flavours interact, but I don't > think that's safe. The IDR (radix tree) will RCU-free nodes, but I > don't think holding the srcu_read_lock is enough to prevent the nodes > being freed. Oh, Indeed, I just saw the Documeentation/RCU/checklist.rst: ``` If the updater uses call_rcu() or synchronize_rcu(), then the corresponding readers may use: (1) rcu_read_lock() and rcu_read_unlock(), (2) any pair of primitives that disables and re-enables softirq, for example, rcu_read_lock_bh() and rcu_read_unlock_bh(), or (3) any pair of primitives that disables and re-enables preemption, for example, rcu_read_lock_sched() and rcu_read_unlock_sched(). If the updater uses synchronize_srcu() or call_srcu(), then the corresponding readers must use srcu_read_lock() and srcu_read_unlock(), and with the same srcu_struct. ``` > I think you'd need to take the rcu_read_lock() around > the call to idr_find(). For latest RCU+refcount method, we call idr_find() under rcu_read_lock(), so it's safe. Thanks, Qi > >> Anyway I will keep working on this issue, and it would be nice if >> there was a way to reproduce it. > > So I think the CVE is inappropriately issued. The SRCU code was added in > v6.4-rc1 and removed before v6.4. I don't think CVEs are appropriate for > bugs which only existed in development kernels. How do we revoke CVEs?