From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793214703; b=mJ5GrEk5Z3U7gqov6X2ItAqFAXjSdO9iTHgGpJUKkDVl6oZI4NVaQJseYRnYUR3g7NLN i+q+KDZpD4wyAOZVAsC9J6utFEWXpMgzY2cdgGY4Odt5QGdt7IFxDyLkkGUOtdDb5WaOV rPsh9ekv+eFBf21sDIgJtY8ZfaWuX4h34lNLiv9JFvXuQXfSmPManQvmpq6vmiJPde8DZ beJnDV3FWNHsQRct75EgAzOVJ3CpFOV7eEQ5+A80mNRYMDZ4vWbo0j8f0B0xbxc6wV0zz HtLWNfk8/+P4LouxnHlBqjsDIeOjVvUxxFvQyGUAlLuSBGzbq0cFTY6tyHZZfbWRHVw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793214703; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=pi6WkH9ySlsB34gINQXki9WyqJK7GM016w1b3VMhl+I=; b=WsDtpKuodZzGslYiNc8rO74hXSvI5i8nsGYq1Ew9/BMB5mea3I/EzFkB4QVjmHShdxOJ kJBeVYEylN8FYXceoaZym2H8Q10HPZ4TfVBLCvS3eVPCysZLHDCUXs+xP01dEVIPLLgmw 54v9j7L2fF8BSfiZ+CipUrp+/gbWGvDZyHBAB6O3CdXYtAFw2yZcRuNFDyB0puJYIYpnv AuGkTlMgcD/wQI4lfa0quLThptInh0pf4it7sGqbqvjJFmCuyGLmzX9AgDehS0rINHfnk F3T6iN6sAuh778YfRKVUBPd24gfQtZNBNYvwZ1z/7Ammw8BMcwCP7mQ6kwThRJkRp2Q== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=0YQJ3gh6; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 26489606A337; Wed, 28 Oct 2026 19:11:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=0YQJ3gh6 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 754CF1F01825; Wed, 28 Oct 2026 19:11:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793214703; bh=pi6WkH9ySlsB34gINQXki9WyqJK7GM016w1b3VMhl+I=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=0YQJ3gh6sYrl26Q5tEEvbcM8NYn9PKkcRe4X/bRmiA4pLuKPLBOzH2x9+IAXXpllr 9+53ZVQ2c6fIICzCVLExJM8CuW6pCLpR4sI8DEZ98cA8ShV4uprI0S0vIwmxV7X4xc 0ofj0ThvXTt2VUAZ0xTwmiKgDphcPWhM+4H0ku30= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Al Viro , Sasha Levin Subject: [PATCH 6.1 0908/1887] functionfs: fix the open/removal races Date: Wed, 28 Oct 2026 17:50:04 +0100 Message-ID: <20261028170520.077523220@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028170459.200466217@linuxfoundation.org> References: <20261028170459.200466217@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Al Viro [ Upstream commit e5bf5ee266633cb18fff6f98f0b7d59a62819eee ] ffs_epfile_open() can race with removal, ending up with file->private_data pointing to freed object. There is a total count of opened files on functionfs (both ep0 and dynamic ones) and when it hits zero, dynamic files get removed. Unfortunately, that removal can happen while another thread is in ffs_epfile_open(), but has not incremented the count yet. In that case open will succeed, leaving us with UAF on any subsequent read() or write(). The root cause is that ffs->opened is misused; atomic_dec_and_test() vs. atomic_add_return() is not a good idea, when object remains visible all along. To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we had zero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from the callback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed, along with checking that state is FFS_ACTIVE. Reviewed-by: Greg Kroah-Hartman Signed-off-by: Al Viro Signed-off-by: Sasha Levin --- drivers/usb/gadget/function/f_fs.c | 54 ++++++++++++++++++++++++------ 1 file changed, 44 insertions(+), 10 deletions(-) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 42095e9b472fa..b3979b24e3186 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -613,13 +613,22 @@ static ssize_t ffs_ep0_read(struct file *file, char __user *buf, static int ffs_ep0_open(struct inode *inode, struct file *file) { - struct ffs_data *ffs = inode->i_private; + struct ffs_data *ffs = inode->i_sb->s_fs_info; + int ret; - if (ffs->state == FFS_CLOSING) - return -EBUSY; + /* Acquire mutex */ + ret = ffs_mutex_lock(&ffs->mutex, file->f_flags & O_NONBLOCK); + if (ret < 0) + return ret; - file->private_data = ffs; ffs_data_opened(ffs); + if (ffs->state == FFS_CLOSING) { + ffs_data_closed(ffs); + mutex_unlock(&ffs->mutex); + return -EBUSY; + } + mutex_unlock(&ffs->mutex); + file->private_data = ffs; return stream_open(inode, file); } @@ -1177,14 +1186,34 @@ static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data) static int ffs_epfile_open(struct inode *inode, struct file *file) { - struct ffs_epfile *epfile = inode->i_private; + struct ffs_data *ffs = inode->i_sb->s_fs_info; + struct ffs_epfile *epfile; + int ret; - if (WARN_ON(epfile->ffs->state != FFS_ACTIVE)) + /* Acquire mutex */ + ret = ffs_mutex_lock(&ffs->mutex, file->f_flags & O_NONBLOCK); + if (ret < 0) + return ret; + + if (!atomic_inc_not_zero(&ffs->opened)) { + mutex_unlock(&ffs->mutex); return -ENODEV; + } + refcount_inc(&ffs->ref); + /* + * we want the state to be FFS_ACTIVE; FFS_ACTIVE alone is + * not enough, though - we might have been through FFS_CLOSING + * and back to FFS_ACTIVE, with our file already removed. + */ + epfile = smp_load_acquire(&inode->i_private); + if (unlikely(ffs->state != FFS_ACTIVE || !epfile)) { + mutex_unlock(&ffs->mutex); + ffs_data_closed(ffs); + return -ENODEV; + } + mutex_unlock(&ffs->mutex); file->private_data = epfile; - ffs_data_opened(epfile->ffs); - return stream_open(inode, file); } @@ -1303,7 +1332,7 @@ static ssize_t ffs_epfile_read_iter(struct kiocb *kiocb, struct iov_iter *to) static int ffs_epfile_release(struct inode *inode, struct file *file) { - struct ffs_epfile *epfile = inode->i_private; + struct ffs_epfile *epfile = file->private_data; ffs_data_closed(epfile->ffs); @@ -1927,6 +1956,11 @@ static int ffs_epfiles_create(struct ffs_data *ffs) return 0; } +static void clear_one(struct dentry *dentry) +{ + smp_store_release(&dentry->d_inode->i_private, NULL); +} + static void ffs_epfiles_destroy(struct ffs_epfile *epfiles, unsigned count) { struct ffs_epfile *epfile = epfiles; @@ -1935,7 +1969,7 @@ static void ffs_epfiles_destroy(struct ffs_epfile *epfiles, unsigned count) BUG_ON(mutex_is_locked(&epfile->mutex)); __ffs_epfile_read_buffer_free(epfile); if (epfile->dentry) { - simple_recursive_removal(epfile->dentry, NULL); + simple_recursive_removal(epfile->dentry, clear_one); epfile->dentry = NULL; } } -- 2.53.0