From bbb66d0c276a7254698eeac82da003f98b023b25 Mon Sep 17 00:00:00 2001 From: CentOS Sources Date: Nov 03 2021 15:28:11 +0000 Subject: import kpatch-patch-4_18_0-305-1-6.el8 --- diff --git a/SOURCES/CVE-2020-36385.patch b/SOURCES/CVE-2020-36385.patch new file mode 100644 index 0000000..08a4e34 --- /dev/null +++ b/SOURCES/CVE-2020-36385.patch @@ -0,0 +1,142 @@ +From 909e24465c59ba4df4124d7caa0730f609c33369 Mon Sep 17 00:00:00 2001 +From: Joe Lawrence +Date: Tue, 26 Oct 2021 18:00:19 -0400 +Subject: [KPATCH CVE-2020-36385] RDMA/ucma: kpatch fixes for CVE-2020-36385 + +Changes since last build: +arches: x86_64 ppc64le +ucma.o: changed function: ucma_migrate_id +--------------------------- + +Kernels: +4.18.0-305.el8 +4.18.0-305.3.1.el8_4 +4.18.0-305.7.1.el8_4 +4.18.0-305.10.2.el8_4 +4.18.0-305.12.1.el8_4 +4.18.0-305.17.1.el8_4 +4.18.0-305.19.1.el8_4 + +Modifications: +Kpatch-MR: https://gitlab.com/redhat/prdsc/rhel/src/kpatch/rhel-8/-/merge_requests/1 +Approved-by: Artem Savkov (@artem.savkov) +- Avoid the complications of reworking all the locks (and preceding +commits) and apply a minimal patch to avoid the CVE condition. +- Always inline ucma_unlock_files() to avoid new function on x64_64 + +Z-MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-8/-/merge_requests/961 + +KT0 test PASS: https://beaker.engineering.redhat.com/jobs/5944203 +for kpatch-patch-4_18_0-305-1-6.el8 scratch build: +https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=40633078 + +commit 15152e7e191054883e2859892e77b442c531d1e1 +Author: Kamal Heib +Date: Sun Mar 7 11:30:04 2021 +0200 + + RDMA/ucma: Rework ucma_migrate_id() to avoid races with destroy + + Bugzilla: https://bugzilla.redhat.com/1982040 + CVE: CVE-2020-36385 + Y-Commit: 20c1e291ce96ca474f5e94272d2e6511c6a38d58 + + O-Bugzilla: http://bugzilla.redhat.com/1931846 + O-CVE: CVE-2020-36385 + + commit f5449e74802c1112dea984aec8af7a33c4516af1 + Author: Jason Gunthorpe + Date: Mon Sep 14 08:59:56 2020 -0300 + + RDMA/ucma: Rework ucma_migrate_id() to avoid races with destroy + + ucma_destroy_id() assumes that all things accessing the ctx will do so via + the xarray. This assumption violated only in the case the FD is being + closed, then the ctx is reached via the ctx_list. Normally this is OK + since ucma_destroy_id() cannot run concurrenty with release(), however + with ucma_migrate_id() is involved this can violated as the close of the + 2nd FD can run concurrently with destroy on the first: + + CPU0 CPU1 + ucma_destroy_id(fda) + ucma_migrate_id(fda -> fdb) + ucma_get_ctx() + xa_lock() + _ucma_find_context() + xa_erase() + xa_unlock() + xa_lock() + ctx->file = new_file + list_move() + xa_unlock() + ucma_put_ctx() + + ucma_close(fdb) + _destroy_id() + kfree(ctx) + + _destroy_id() + wait_for_completion() + // boom, ctx was freed + + The ctx->file must be modified under the handler and xa_lock, and prior to + modification the ID must be rechecked that it is still reachable from + cur_file, ie there is no parallel destroy or migrate. + + To make this work remove the double locking and streamline the control + flow. The double locking was obsoleted by the handler lock now directly + preventing new uevents from being created, and the ctx_list cannot be read + while holding fgets on both files. Removing the double locking also + removes the need to check for the same file. + + Fixes: 88314e4dda1e ("RDMA/cma: add support for rdma_migrate_id()") + Link: https://lore.kernel.org/r/0-v1-05c5a4090305+3a872-ucma_syz_migrate_jgg@nvidia.com + Reported-and-tested-by: syzbot+cc6fc752b3819e082d0c@syzkaller.appspotmail.com + Signed-off-by: Jason Gunthorpe + + Signed-off-by: Kamal Heib + +Signed-off-by: Joe Lawrence +--- + drivers/infiniband/core/ucma.c | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c +index 138e0096ca8e..2cd4277bf4a8 100644 +--- a/drivers/infiniband/core/ucma.c ++++ b/drivers/infiniband/core/ucma.c +@@ -1626,7 +1626,7 @@ static void ucma_lock_files(struct ucma_file *file1, struct ucma_file *file2) + } + } + +-static void ucma_unlock_files(struct ucma_file *file1, struct ucma_file *file2) ++static __always_inline void ucma_unlock_files(struct ucma_file *file1, struct ucma_file *file2) + { + if (file1 < file2) { + mutex_unlock(&file2->mut); +@@ -1689,6 +1689,14 @@ static ssize_t ucma_migrate_id(struct ucma_file *new_file, + ucma_lock_files(cur_file, new_file); + xa_lock(&ctx_table); + ++ /* CVE-2020-36385 kpatch: double check the context one last time */ ++ if (_ucma_find_context(cmd.id, cur_file) != ctx) { ++ xa_unlock(&ctx_table); ++ ucma_unlock_files(cur_file, new_file); ++ ret = -ENOENT; ++ goto err_unlock; ++ } ++ + list_move_tail(&ctx->list, &new_file->ctx_list); + ucma_move_events(ctx, new_file); + ctx->file = new_file; +@@ -1702,6 +1710,7 @@ static ssize_t ucma_migrate_id(struct ucma_file *new_file, + &resp, sizeof(resp))) + ret = -EFAULT; + ++err_unlock: + ucma_put_ctx(ctx); + file_put: + fdput(f); +-- +2.31.1 + + diff --git a/SOURCES/CVE-2021-0512.patch b/SOURCES/CVE-2021-0512.patch new file mode 100644 index 0000000..24f94eb --- /dev/null +++ b/SOURCES/CVE-2021-0512.patch @@ -0,0 +1,116 @@ +From cd6338e72336f073342df3b49a4d6cb7fb6cdbee Mon Sep 17 00:00:00 2001 +From: Joe Lawrence +Date: Tue, 26 Oct 2021 10:59:31 -0400 +Subject: [KPATCH CVE-2021-0512] HID: kpatch fixes for CVE-2021-0512 + +Kernels: +4.18.0-305.el8 +4.18.0-305.3.1.el8_4 +4.18.0-305.7.1.el8_4 +4.18.0-305.10.2.el8_4 +4.18.0-305.12.1.el8_4 +4.18.0-305.17.1.el8_4 +4.18.0-305.19.1.el8_4 + +Changes since last build: +arches: x86_64 ppc64le +hid-core.o: changed function: hid_add_field +--------------------------- + +Kernels: +4.18.0-305.el8 +4.18.0-305.3.1.el8_4 +4.18.0-305.7.1.el8_4 +4.18.0-305.10.2.el8_4 +4.18.0-305.12.1.el8_4 +4.18.0-305.17.1.el8_4 +4.18.0-305.19.1.el8_4 + +Modifications: none +Kpatch-MR: https://gitlab.com/redhat/prdsc/rhel/src/kpatch/rhel-8/-/merge_requests/5 +Approved-by: Artem Savkov (@artem.savkov) + +Z-MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-8/-/merge_requests/1350 + +KT0 test PASS: https://beaker.engineering.redhat.com/jobs/5942710 +for kpatch-patch-4_18_0-305-1-6.el8 scratch build: +https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=40615898 + +commit 8ee375b059ce42c0c38f2593f76077d915eee89e +Author: Benjamin Tissoires +Date: Tue Aug 17 09:26:20 2021 +0200 + + HID: make arrays usage and value to be the same + + Bugzilla: https://bugzilla.redhat.com/1974941 + CVE: CVE-2021-0512 + Y-Commit: 87ed552fb937790a5d9439c179bb523cfb0efdc6 + + O-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1974942 + Upstream Status: since v5.12 + Test: me on the hid-tools test suite + + commit ed9be64eefe26d7d8b0b5b9fa3ffdf425d87a01f + Author: Will McVicker + Date: Sat Dec 5 00:48:48 2020 +0000 + + HID: make arrays usage and value to be the same + + The HID subsystem allows an "HID report field" to have a different + number of "values" and "usages" when it is allocated. When a field + struct is created, the size of the usage array is guaranteed to be at + least as large as the values array, but it may be larger. This leads to + a potential out-of-bounds write in + __hidinput_change_resolution_multipliers() and an out-of-bounds read in + hidinput_count_leds(). + + To fix this, let's make sure that both the usage and value arrays are + the same size. + + Cc: stable@vger.kernel.org + Signed-off-by: Will McVicker + Signed-off-by: Jiri Kosina + + Signed-off-by: Benjamin Tissoires + Signed-off-by: Julio Faracco + +Signed-off-by: Joe Lawrence +--- + drivers/hid/hid-core.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c +index d2ecc9c45255..263eca119ff0 100644 +--- a/drivers/hid/hid-core.c ++++ b/drivers/hid/hid-core.c +@@ -90,7 +90,7 @@ EXPORT_SYMBOL_GPL(hid_register_report); + * Register a new field for this report. + */ + +-static struct hid_field *hid_register_field(struct hid_report *report, unsigned usages, unsigned values) ++static struct hid_field *hid_register_field(struct hid_report *report, unsigned usages) + { + struct hid_field *field; + +@@ -101,7 +101,7 @@ static struct hid_field *hid_register_field(struct hid_report *report, unsigned + + field = kzalloc((sizeof(struct hid_field) + + usages * sizeof(struct hid_usage) + +- values * sizeof(unsigned)), GFP_KERNEL); ++ usages * sizeof(unsigned)), GFP_KERNEL); + if (!field) + return NULL; + +@@ -300,7 +300,7 @@ static int hid_add_field(struct hid_parser *parser, unsigned report_type, unsign + usages = max_t(unsigned, parser->local.usage_index, + parser->global.report_count); + +- field = hid_register_field(report, usages, parser->global.report_count); ++ field = hid_register_field(report, usages); + if (!field) + return 0; + +-- +2.31.1 + + diff --git a/SPECS/kpatch-patch.spec b/SPECS/kpatch-patch.spec index ef9b0fb..53338b8 100644 --- a/SPECS/kpatch-patch.spec +++ b/SPECS/kpatch-patch.spec @@ -6,7 +6,7 @@ %define kernel_ver 4.18.0-305.el8 %define kpatch_ver 0.9.3 %define rpm_ver 1 -%define rpm_rel 5 +%define rpm_rel 6 %if !%{empty_package} # Patch sources below. DO NOT REMOVE THIS LINE. @@ -34,6 +34,12 @@ Source106: CVE-2021-3609.patch # # https://bugzilla.redhat.com/1988230 Source107: CVE-2021-37576.patch +# +# https://bugzilla.redhat.com/1981706 +Source108: CVE-2020-36385.patch +# +# https://bugzilla.redhat.com/1979028 +Source109: CVE-2021-0512.patch # End of patch sources. DO NOT REMOVE THIS LINE. %endif @@ -53,7 +59,7 @@ Summary: Live kernel patching module for kernel-%{kernel_ver_arch} Group: System Environment/Kernel License: GPLv2 -ExclusiveArch: ppc64le +ExclusiveArch: x86_64 ppc64le Conflicts: %{name} < %{version}-%{release} @@ -172,6 +178,10 @@ It is only a method to subscribe to the kpatch stream for kernel-%{kernel_ver}. %endif %changelog +* Wed Oct 27 2021 Artem Savkov [1-6.el8] +- out-of-bounds write due to a heap buffer overflow in __hidinput_change_resolution_multipliers() [1979028] {CVE-2021-0512} +- use-after-free in drivers/infiniband/core/ucma.c ctx use-after-free [1981706] {CVE-2020-36385} + * Wed Sep 01 2021 Artem Savkov [1-5.el8] - powerpc: KVM guest OS users can cause host OS memory corruption [1988230] {CVE-2021-37576}