5.10-stable patches

added patches:
	net-9p-initialize-the-iounit-field-during-fid-creation.patch
	net_sched-cls_route-disallow-handle-of-0.patch
	sched-fair-fix-fault-in-reweight_entity.patch
	tee-add-overflow-check-in-register_shm_helper.patch

diff --git a/queue-5.10/net-9p-initialize-the-iounit-field-during-fid-creation.patch b/queue-5.10/net-9p-initialize-the-iounit-field-during-fid-creation.patch
new file mode 100644 (file)
index 0000000..bb011f3
--- /dev/null
+++ b/queue-5.10/net-9p-initialize-the-iounit-field-during-fid-creation.patch
@@ -0,0 +1,69 @@
+From aa7aeee169480e98cf41d83c01290a37e569be6d Mon Sep 17 00:00:00 2001
+From: Tyler Hicks <tyhicks@linux.microsoft.com>
+Date: Sun, 10 Jul 2022 09:14:02 -0500
+Subject: net/9p: Initialize the iounit field during fid creation
+
+From: Tyler Hicks <tyhicks@linux.microsoft.com>
+
+commit aa7aeee169480e98cf41d83c01290a37e569be6d upstream.
+
+Ensure that the fid's iounit field is set to zero when a new fid is
+created. Certain 9P operations, such as OPEN and CREATE, allow the
+server to reply with an iounit size which the client code assigns to the
+p9_fid struct shortly after the fid is created by p9_fid_create(). On
+the other hand, an XATTRWALK operation doesn't allow for the server to
+specify an iounit value. The iounit field of the newly allocated p9_fid
+struct remained uninitialized in that case. Depending on allocation
+patterns, the iounit value could have been something reasonable that was
+carried over from previously freed fids or, in the worst case, could
+have been arbitrary values from non-fid related usages of the memory
+location.
+
+The bug was detected in the Windows Subsystem for Linux 2 (WSL2) kernel
+after the uninitialized iounit field resulted in the typical sequence of
+two getxattr(2) syscalls, one to get the size of an xattr and another
+after allocating a sufficiently sized buffer to fit the xattr value, to
+hit an unexpected ERANGE error in the second call to getxattr(2). An
+uninitialized iounit field would sometimes force rsize to be smaller
+than the xattr value size in p9_client_read_once() and the 9P server in
+WSL refused to chunk up the READ on the attr_fid and, instead, returned
+ERANGE to the client. The virtfs server in QEMU seems happy to chunk up
+the READ and this problem goes undetected there.
+
+Link: https://lkml.kernel.org/r/20220710141402.803295-1-tyhicks@linux.microsoft.com
+Fixes: ebf46264a004 ("fs/9p: Add support user. xattr")
+Cc: stable@vger.kernel.org
+Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com>
+Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
+Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
+[tyhicks: Adjusted context due to:
+ - Lack of fid refcounting introduced in v5.11 commit 6636b6dcc3db ("9p:
+   add refcount to p9_fid struct")
+ - Difference in how buffer sizes are specified v5.16 commit
+   6e195b0f7c8e ("9p: fix a bunch of checkpatch warnings")]
+Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/9p/client.c |    5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+--- a/net/9p/client.c
++++ b/net/9p/client.c
+@@ -893,16 +893,13 @@ static struct p9_fid *p9_fid_create(stru
+       struct p9_fid *fid;
+ 
+       p9_debug(P9_DEBUG_FID, "clnt %p\n", clnt);
+-      fid = kmalloc(sizeof(struct p9_fid), GFP_KERNEL);
++      fid = kzalloc(sizeof(struct p9_fid), GFP_KERNEL);
+       if (!fid)
+               return NULL;
+ 
+-      memset(&fid->qid, 0, sizeof(struct p9_qid));
+       fid->mode = -1;
+       fid->uid = current_fsuid();
+       fid->clnt = clnt;
+-      fid->rdir = NULL;
+-      fid->fid = 0;
+ 
+       idr_preload(GFP_KERNEL);
+       spin_lock_irq(&clnt->lock);

diff --git a/queue-5.10/net_sched-cls_route-disallow-handle-of-0.patch b/queue-5.10/net_sched-cls_route-disallow-handle-of-0.patch
new file mode 100644 (file)
index 0000000..5ea429d
--- /dev/null
+++ b/queue-5.10/net_sched-cls_route-disallow-handle-of-0.patch
@@ -0,0 +1,87 @@
+From 02799571714dc5dd6948824b9d080b44a295f695 Mon Sep 17 00:00:00 2001
+From: Jamal Hadi Salim <jhs@mojatatu.com>
+Date: Sun, 14 Aug 2022 11:27:58 +0000
+Subject: net_sched: cls_route: disallow handle of 0
+
+From: Jamal Hadi Salim <jhs@mojatatu.com>
+
+commit 02799571714dc5dd6948824b9d080b44a295f695 upstream.
+
+Follows up on:
+https://lore.kernel.org/all/20220809170518.164662-1-cascardo@canonical.com/
+
+handle of 0 implies from/to of universe realm which is not very
+sensible.
+
+Lets see what this patch will do:
+$sudo tc qdisc add dev $DEV root handle 1:0 prio
+
+//lets manufacture a way to insert handle of 0
+$sudo tc filter add dev $DEV parent 1:0 protocol ip prio 100 \
+route to 0 from 0 classid 1:10 action ok
+
+//gets rejected...
+Error: handle of 0 is not valid.
+We have an error talking to the kernel, -1
+
+//lets create a legit entry..
+sudo tc filter add dev $DEV parent 1:0 protocol ip prio 100 route from 10 \
+classid 1:10 action ok
+
+//what did the kernel insert?
+$sudo tc filter ls dev $DEV parent 1:0
+filter protocol ip pref 100 route chain 0
+filter protocol ip pref 100 route chain 0 fh 0x000a8000 flowid 1:10 from 10
+       action order 1: gact action pass
+        random type none pass val 0
+        index 1 ref 1 bind 1
+
+//Lets try to replace that legit entry with a handle of 0
+$ sudo tc filter replace dev $DEV parent 1:0 protocol ip prio 100 \
+handle 0x000a8000 route to 0 from 0 classid 1:10 action drop
+
+Error: Replacing with handle of 0 is invalid.
+We have an error talking to the kernel, -1
+
+And last, lets run Cascardo's POC:
+$ ./poc
+0
+0
+-22
+-22
+-22
+
+Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
+Acked-by: Stephen Hemminger <stephen@networkplumber.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sched/cls_route.c |   10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/net/sched/cls_route.c
++++ b/net/sched/cls_route.c
+@@ -424,6 +424,11 @@ static int route4_set_parms(struct net *
+                       return -EINVAL;
+       }
+ 
++      if (!nhandle) {
++              NL_SET_ERR_MSG(extack, "Replacing with handle of 0 is invalid");
++              return -EINVAL;
++      }
++
+       h1 = to_hash(nhandle);
+       b = rtnl_dereference(head->table[h1]);
+       if (!b) {
+@@ -477,6 +482,11 @@ static int route4_change(struct net *net
+       int err;
+       bool new = true;
+ 
++      if (!handle) {
++              NL_SET_ERR_MSG(extack, "Creating with handle of 0 is invalid");
++              return -EINVAL;
++      }
++
+       if (opt == NULL)
+               return handle ? -EINVAL : 0;
+ 

diff --git a/queue-5.10/sched-fair-fix-fault-in-reweight_entity.patch b/queue-5.10/sched-fair-fix-fault-in-reweight_entity.patch
new file mode 100644 (file)
index 0000000..501cbcc
--- /dev/null
+++ b/queue-5.10/sched-fair-fix-fault-in-reweight_entity.patch
@@ -0,0 +1,101 @@
+From 13765de8148f71fa795e0a6607de37c49ea5915a Mon Sep 17 00:00:00 2001
+From: Tadeusz Struk <tadeusz.struk@linaro.org>
+Date: Thu, 3 Feb 2022 08:18:46 -0800
+Subject: sched/fair: Fix fault in reweight_entity
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Tadeusz Struk <tadeusz.struk@linaro.org>
+
+commit 13765de8148f71fa795e0a6607de37c49ea5915a upstream.
+
+Syzbot found a GPF in reweight_entity. This has been bisected to
+commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid
+sched_task_group")
+
+There is a race between sched_post_fork() and setpriority(PRIO_PGRP)
+within a thread group that causes a null-ptr-deref in
+reweight_entity() in CFS. The scenario is that the main process spawns
+number of new threads, which then call setpriority(PRIO_PGRP, 0, -20),
+wait, and exit.  For each of the new threads the copy_process() gets
+invoked, which adds the new task_struct and calls sched_post_fork()
+for it.
+
+In the above scenario there is a possibility that
+setpriority(PRIO_PGRP) and set_one_prio() will be called for a thread
+in the group that is just being created by copy_process(), and for
+which the sched_post_fork() has not been executed yet. This will
+trigger a null pointer dereference in reweight_entity(), as it will
+try to access the run queue pointer, which hasn't been set.
+
+Before the mentioned change the cfs_rq pointer for the task  has been
+set in sched_fork(), which is called much earlier in copy_process(),
+before the new task is added to the thread_group.  Now it is done in
+the sched_post_fork(), which is called after that.  To fix the issue
+the remove the update_load param from the update_load param() function
+and call reweight_task() only if the task flag doesn't have the
+TASK_NEW flag set.
+
+Fixes: 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid sched_task_group")
+Reported-by: syzbot+af7a719bc92395ee41b3@syzkaller.appspotmail.com
+Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20220203161846.1160750-1-tadeusz.struk@linaro.org
+Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/sched/core.c |   11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+--- a/kernel/sched/core.c
++++ b/kernel/sched/core.c
+@@ -844,8 +844,9 @@ int tg_nop(struct task_group *tg, void *
+ }
+ #endif
+ 
+-static void set_load_weight(struct task_struct *p, bool update_load)
++static void set_load_weight(struct task_struct *p)
+ {
++      bool update_load = !(READ_ONCE(p->state) & TASK_NEW);
+       int prio = p->static_prio - MAX_RT_PRIO;
+       struct load_weight *load = &p->se.load;
+ 
+@@ -3266,7 +3267,7 @@ int sched_fork(unsigned long clone_flags
+                       p->static_prio = NICE_TO_PRIO(0);
+ 
+               p->prio = p->normal_prio = p->static_prio;
+-              set_load_weight(p, false);
++              set_load_weight(p);
+ 
+               /*
+                * We don't need the reset flag anymore after the fork. It has
+@@ -5015,7 +5016,7 @@ void set_user_nice(struct task_struct *p
+               put_prev_task(rq, p);
+ 
+       p->static_prio = NICE_TO_PRIO(nice);
+-      set_load_weight(p, true);
++      set_load_weight(p);
+       old_prio = p->prio;
+       p->prio = effective_prio(p);
+ 
+@@ -5188,7 +5189,7 @@ static void __setscheduler_params(struct
+        */
+       p->rt_priority = attr->sched_priority;
+       p->normal_prio = normal_prio(p);
+-      set_load_weight(p, true);
++      set_load_weight(p);
+ }
+ 
+ /*
+@@ -7200,7 +7201,7 @@ void __init sched_init(void)
+               atomic_set(&rq->nr_iowait, 0);
+       }
+ 
+-      set_load_weight(&init_task, false);
++      set_load_weight(&init_task);
+ 
+       /*
+        * The boot idle thread does lazy MMU switching as well:

diff --git a/queue-5.10/series b/queue-5.10/series
index 1ea05824705a02be7a0a293a40ed3c26c9f41818..dc1468948a5223ef77b299f57a8b51b8ad632d19 100644 (file)
--- a/queue-5.10/series
+++ b/queue-5.10/series
@@ -537,3 +537,7 @@ revert-net-usb-ax88179_178a-needs-flag_send_zlp.patch
 bluetooth-l2cap-fix-l2cap_global_chan_by_psm-regression.patch
 mtd-rawnand-arasan-prevent-an-unsupported-configuration.patch
 kvm-x86-pmu-fix-the-compare-function-used-by-the-pmu-event-filter.patch
+tee-add-overflow-check-in-register_shm_helper.patch
+net-9p-initialize-the-iounit-field-during-fid-creation.patch
+net_sched-cls_route-disallow-handle-of-0.patch
+sched-fair-fix-fault-in-reweight_entity.patch

diff --git a/queue-5.10/tee-add-overflow-check-in-register_shm_helper.patch b/queue-5.10/tee-add-overflow-check-in-register_shm_helper.patch
new file mode 100644 (file)
index 0000000..c5f847c
--- /dev/null
+++ b/queue-5.10/tee-add-overflow-check-in-register_shm_helper.patch
@@ -0,0 +1,59 @@
+From 573ae4f13f630d6660008f1974c0a8a29c30e18a Mon Sep 17 00:00:00 2001
+From: Jens Wiklander <jens.wiklander@linaro.org>
+Date: Thu, 18 Aug 2022 13:08:59 +0200
+Subject: tee: add overflow check in register_shm_helper()
+
+From: Jens Wiklander <jens.wiklander@linaro.org>
+
+commit 573ae4f13f630d6660008f1974c0a8a29c30e18a upstream.
+
+With special lengths supplied by user space, register_shm_helper() has
+an integer overflow when calculating the number of pages covered by a
+supplied user space memory region.
+
+This causes internal_get_user_pages_fast() a helper function of
+pin_user_pages_fast() to do a NULL pointer dereference:
+
+  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
+  Modules linked in:
+  CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11
+  Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
+  pc : internal_get_user_pages_fast+0x474/0xa80
+  Call trace:
+   internal_get_user_pages_fast+0x474/0xa80
+   pin_user_pages_fast+0x24/0x4c
+   register_shm_helper+0x194/0x330
+   tee_shm_register_user_buf+0x78/0x120
+   tee_ioctl+0xd0/0x11a0
+   __arm64_sys_ioctl+0xa8/0xec
+   invoke_syscall+0x48/0x114
+
+Fix this by adding an an explicit call to access_ok() in
+tee_shm_register_user_buf() to catch an invalid user space address
+early.
+
+Fixes: 033ddf12bcf5 ("tee: add register user memory")
+Cc: stable@vger.kernel.org
+Reported-by: Nimish Mishra <neelam.nimish@gmail.com>
+Reported-by: Anirban Chakraborty <ch.anirban00727@gmail.com>
+Reported-by: Debdeep Mukhopadhyay <debdeep.mukhopadhyay@gmail.com>
+Suggested-by: Jerome Forissier <jerome.forissier@linaro.org>
+Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tee/tee_shm.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/tee/tee_shm.c
++++ b/drivers/tee/tee_shm.c
+@@ -222,6 +222,9 @@ struct tee_shm *tee_shm_register(struct
+               goto err;
+       }
+ 
++      if (!access_ok((void __user *)addr, length))
++              return ERR_PTR(-EFAULT);
++
+       mutex_lock(&teedev->mutex);
+       shm->id = idr_alloc(&teedev->idr, shm, 1, 0, GFP_KERNEL);
+       mutex_unlock(&teedev->mutex);