From 7dd3ed26ca09df0e582be8cc2780bba588bdd11e Mon Sep 17 00:00:00 2001 From: P Dheeraj Srujan Kumar Date: Fri, 2 Dec 2022 23:23:31 +0530 Subject: Update to internal 1-0.92 Signed-off-by: P Dheeraj Srujan Kumar --- .../linux/linux-aspeed/CVE-2021-4083.patch | 64 ++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-4083.patch (limited to 'meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-4083.patch') diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-4083.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-4083.patch new file mode 100644 index 000000000..233085359 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2021-4083.patch @@ -0,0 +1,64 @@ +From 6fe4eadd54da3040cf6f6579ae157ae1395dc0f8 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Wed, 1 Dec 2021 10:06:14 -0800 +Subject: [PATCH] fget: check that the fd still exists after getting a ref to + it + +commit 054aa8d439b9185d4f5eb9a90282d1ce74772969 upstream. + +Jann Horn points out that there is another possible race wrt Unix domain +socket garbage collection, somewhat reminiscent of the one fixed in +commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK"). + +See the extended comment about the garbage collection requirements added +to unix_peek_fds() by that commit for details. + +The race comes from how we can locklessly look up a file descriptor just +as it is in the process of being closed, and with the right artificial +timing (Jann added a few strategic 'mdelay(500)' calls to do that), the +Unix domain socket garbage collector could see the reference count +decrement of the close() happen before fget() took its reference to the +file and the file was attached onto a new file descriptor. + +This is all (intentionally) correct on the 'struct file *' side, with +RCU lookups and lockless reference counting very much part of the +design. Getting that reference count out of order isn't a problem per +se. + +But the garbage collector can get confused by seeing this situation of +having seen a file not having any remaining external references and then +seeing it being attached to an fd. + +In commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK") the +fix was to serialize the file descriptor install with the garbage +collector by taking and releasing the unix_gc_lock. + +That's not really an option here, but since this all happens when we are +in the process of looking up a file descriptor, we can instead simply +just re-check that the file hasn't been closed in the meantime, and just +re-do the lookup if we raced with a concurrent close() of the same file +descriptor. + +Reported-and-tested-by: Jann Horn +Acked-by: Miklos Szeredi +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + fs/file.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/fs/file.c b/fs/file.c +index 8627dacfc4246f..ad4a8bf3cf109f 100644 +--- a/fs/file.c ++++ b/fs/file.c +@@ -858,6 +858,10 @@ static struct file *__fget_files(struct files_struct *files, unsigned int fd, + file = NULL; + else if (!get_file_rcu_many(file, refs)) + goto loop; ++ else if (files_lookup_fd_raw(files, fd) != file) { ++ fput_many(file, refs); ++ goto loop; ++ } + } + rcu_read_unlock(); + -- cgit v1.2.3