From f32993b1114f1004aaf4cabb9c409ee18e521c95 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 19 Aug 2022 13:26:54 +0200 Subject: [PATCH] 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 --- ...the-iounit-field-during-fid-creation.patch | 69 ++++++++++++ ...sched-cls_route-disallow-handle-of-0.patch | 87 +++++++++++++++ ...ed-fair-fix-fault-in-reweight_entity.patch | 101 ++++++++++++++++++ queue-5.10/series | 4 + ...verflow-check-in-register_shm_helper.patch | 59 ++++++++++ 5 files changed, 320 insertions(+) create mode 100644 queue-5.10/net-9p-initialize-the-iounit-field-during-fid-creation.patch create mode 100644 queue-5.10/net_sched-cls_route-disallow-handle-of-0.patch create mode 100644 queue-5.10/sched-fair-fix-fault-in-reweight_entity.patch create mode 100644 queue-5.10/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 index 00000000000..bb011f38dae --- /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 +Date: Sun, 10 Jul 2022 09:14:02 -0500 +Subject: net/9p: Initialize the iounit field during fid creation + +From: Tyler Hicks + +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 +Reviewed-by: Christian Schoenebeck +Signed-off-by: Dominique Martinet +[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 +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..5ea429da45c --- /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 +Date: Sun, 14 Aug 2022 11:27:58 +0000 +Subject: net_sched: cls_route: disallow handle of 0 + +From: Jamal Hadi Salim + +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 +Acked-by: Stephen Hemminger +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 00000000000..501cbcccf97 --- /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 +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 + +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 +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Dietmar Eggemann +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20220203161846.1160750-1-tadeusz.struk@linaro.org +Signed-off-by: Fedor Pchelkin +Signed-off-by: Greg Kroah-Hartman +--- + 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 1ea05824705..dc1468948a5 100644 --- 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 index 00000000000..c5f847c8b77 --- /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 +Date: Thu, 18 Aug 2022 13:08:59 +0200 +Subject: tee: add overflow check in register_shm_helper() + +From: Jens Wiklander + +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 +Reported-by: Anirban Chakraborty +Reported-by: Debdeep Mukhopadhyay +Suggested-by: Jerome Forissier +Signed-off-by: Jens Wiklander +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + 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); -- 2.47.3