Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp2480430pxf; Sun, 4 Apr 2021 03:10:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw2qu7IczFawrnk2ABHiPItTb/sPr5+qUDVA3j6CIZK75fTZXQBBr3OotXjAWjmXEwnugw6 X-Received: by 2002:a17:906:bcc8:: with SMTP id lw8mr4913624ejb.321.1617531057891; Sun, 04 Apr 2021 03:10:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617531057; cv=none; d=google.com; s=arc-20160816; b=DM/7t0DQTR8l4OsV74WBkS/0p4MwEsZ4AhOUjg2psngpb5DlcCghYaeqOt3U75q3tT NNr5W9Rc5yBGyrzKAoszOgyuxDrMkque2uBk0C0a85xKP/2MT/t1gbUKyetXOjXpiPJr scaYlVxp7Ri24N/OR8iMiq0AFdTfdV/inbLPsvPYcKnDBYFs6dgnLe8whsOeRK9bS7Tp /dGKab3Y5IecQgEUps8jNdG6SNX5+RT+HAvhhmfgqC237mV317xhJLwqGD9M6Gzh3bnb WScy4FjdjW1XpnfhsuWDIzsnG18GTt8DYuGz9SXDTfiTEyxFJQk+i91dNkq6lcs4yfeL ymwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=YyFWNQbFjzqQMXREpTHaLfKBIJsSJScF8WfbAhO4hJo=; b=Lyjz6m9/qVxEq6PHMuHGeE7i9U9lYa9543Hu6889/H1pk30qynZzoKzAOgtV9Y0otz 6+VsH+lktotQDoX+psSMI0MqUZ7wQ1ouWrT3TAdXEHPzk9QUylwVaanDjciXbtq6LZW3 fRHzSjo2c6mFVeCpYKaa9U8mebB55LF3ha3wg4/UMrljJ55BZeum3MIF8ppdQqL5UVCW WcpK+hy/hbV595nKlub9O4/M0ZL7e5UqgMbiHiFJazy3Wc01XJfhhRLfimrYbVNAYDUg hOciIiRT8AKl+MGwxoVzfGgoHIuPBKNfwfcVNE4WhPYJrn9bkF0s0+N7fDki01CpIZh8 xmYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=reXhkqEH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y8si11455322edc.279.2021.04.04.03.10.35; Sun, 04 Apr 2021 03:10:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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=@linuxfoundation.org header.s=korg header.b=reXhkqEH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229709AbhDDKIM (ORCPT + 99 others); Sun, 4 Apr 2021 06:08:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:50892 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229578AbhDDKIL (ORCPT ); Sun, 4 Apr 2021 06:08:11 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D0ED6610CB; Sun, 4 Apr 2021 10:08:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617530885; bh=YyFWNQbFjzqQMXREpTHaLfKBIJsSJScF8WfbAhO4hJo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=reXhkqEHty7WHp9aNF6kuyLl339Ua3ZUmBohwVFOpOXewmXA1eHXdg2uu4zN71AgE gxUrXsfLBAJlvgXLUHtqOxDFMMIG4jYWew1MWArbu0zf2HahwaOzdiM4cF4nRYAB0k Wj7xrumCgiVReGYhXnQj+h71zuM8P7K6XTvHcct8= Date: Sun, 4 Apr 2021 12:08:01 +0200 From: Greg Kroah-Hartman To: Samuel Holland Cc: "Rafael J. Wysocki" , Arend van Spriel , linux-kernel@vger.kernel.org Subject: Re: [PATCH] debugfs: Fix use-after-free in debugfs_create_devm_seqfile() Message-ID: References: <20210404004504.5547-1-samuel@sholland.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210404004504.5547-1-samuel@sholland.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 03, 2021 at 07:45:04PM -0500, Samuel Holland wrote: > This function uses devres to clean up its allocation, but it never removes the > file referencing that allocation. This causes a use-after-free and an oops if > the file is accessed after the owning device is removed. What in-kernel user of this is having this problem? The driver should clean up the debugfs file, it is not the debugfs core's job to auto-remove the file. The resource is what is being cleaned up by the devm usage in debugfs, that's all, not the file. Please fix up the driver that is creating the file but then not removing it. thanks, greg k-h