All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kyle Zeng <zengyhkyle@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>, stable@vger.kernel.org
Cc: sishuai@purdue.edu, hch@lst.de
Subject: Re: [PATCH] configfs: fix a race in configfs_lookup()
Date: Sat, 2 Sep 2023 14:55:14 -0700	[thread overview]
Message-ID: <ZPOvQjsauIgSik3k@westworld> (raw)
In-Reply-To: <2023090247-sneezing-latch-af81@gregkh>

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

> You lost all the original signed-off-by lines of the original, AND you
> lost the authorship of the original commit.  And you didn't cc: anyone
> involved in the original patch, to get their review, or objection to it
> being backported.
Sorry for the rookie mistakes. I drafted another version and it is
attached to the email. Can you please check whether it is OK?

> Also, how did you test this change?  is this something that you have
> actually hit in real life?
Yes. I encountered this when testing the latest v5.10.y branch. A
minimal proof-of-concept code looks like this:
~~~
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>

int main(void)
{
	int fd = open("/sys/kernel/config", 0);

	if(!fork()) {
		while(1) lseek(fd, SEEK_CUR, 1);
	}
	while(1) unlinkat(fd, "file", 0);

	return 0;
}
~~~

[-- Attachment #2: 0001-configfs-fix-a-race-in-configfs_lookup.patch --]
[-- Type: text/x-diff, Size: 1943 bytes --]

From 366d165e876a14a5b25ad741fdcd8658aa7e690d Mon Sep 17 00:00:00 2001
From: Kyle Zeng <zengyhkyle@gmail.com>
Date: Fri, 1 Sep 2023 17:41:14 -0700
Subject: [PATCH v5.10.y] configfs: fix a race in configfs_lookup()

commit c42dd069be8dfc9b2239a5c89e73bbd08ab35de0 upstream.

configfs: fix a race in configfs_lookup()
When configfs_lookup() is executing list_for_each_entry(),
it is possible that configfs_dir_lseek() is calling list_del().
Some unfortunate interleavings of them can cause a kernel NULL
pointer dereference error

Thread 1                  Thread 2
//configfs_dir_lseek()    //configfs_lookup()
list_del(&cursor->s_sibling);
                         list_for_each_entry(sd, ...)

Fix this by grabbing configfs_dirent_lock in configfs_lookup()
while iterating ->s_children.

Signed-off-by: Sishuai Gong <sishuai@purdue.edu>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Kyle Zeng <zengyhkyle@gmail.com>
---
Please apply this patch to v5.10.y. This patch adapts the original patch
to v5.10.y considering codebase change.
The idea is to hold the configfs_dirent_lock when traversing
->s_children, which follows the core idea of the original patch.

This patch has been tested against the v5.10.y stable tree.

 fs/configfs/dir.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index 12388ed4faa5..0b7e9ab517d5 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -479,6 +479,7 @@ static struct dentry * configfs_lookup(struct inode *dir,
 	if (!configfs_dirent_is_ready(parent_sd))
 		goto out;
 
+	spin_lock(&configfs_dirent_lock);
 	list_for_each_entry(sd, &parent_sd->s_children, s_sibling) {
 		if (sd->s_type & CONFIGFS_NOT_PINNED) {
 			const unsigned char * name = configfs_get_name(sd);
@@ -491,6 +492,7 @@ static struct dentry * configfs_lookup(struct inode *dir,
 			break;
 		}
 	}
+	spin_unlock(&configfs_dirent_lock);
 
 	if (!found) {
 		/*
-- 
2.34.1


  reply	other threads:[~2023-09-02 21:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-02 20:20 [PATCH] configfs: fix a race in configfs_lookup() Kyle Zeng
2023-09-02 21:08 ` Greg KH
2023-09-02 21:55   ` Kyle Zeng [this message]
2023-09-03  8:45     ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZPOvQjsauIgSik3k@westworld \
    --to=zengyhkyle@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=sishuai@purdue.edu \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.