From d755c1f10a580e972fafb7bebf24378b5b830b98 Mon Sep 17 00:00:00 2001
From: Ryan Sullivan <rysulliv@redhat.com>
Date: Tue, 7 Nov 2023 15:04:48 -0500
Subject: [KPATCH CVE-2023-4128] kpatch fixes for CVE-2023-4128
Kernels:
3.10.0-1160.90.1.el7
3.10.0-1160.92.1.el7
3.10.0-1160.95.1.el7
3.10.0-1160.99.1.el7
3.10.0-1160.102.1.el7
Kpatch-MR: https://gitlab.com/redhat/prdsc/rhel/src/kpatch/rhel-7/-/merge_requests/62
Approved-by: Joe Lawrence (@joe.lawrence)
Approved-by: Yannick Cote (@ycote1)
Changes since last build:
arches: x86_64 ppc64le
cls_fw.o: changed function: fw_change
cls_fw.o: changed function: fw_set_parms
cls_route.o: changed function: route4_change
cls_u32.o: changed function: u32_change
sch_qfq.o: changed function: qfq_enqueue
---------------------------
Modifications: none
commit 726e9f3d88c729cdae09768c94e588deebdb9d52
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date: Mon Jan 23 17:17:17 2023 -0300
KVM: x86: rename argument to kvm_set_tsc_khz
commit 4941b8cb3746f09bb102f7a5d64d878e96a0c6cd
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2152838
JIRA: https://issues.redhat.com/browse/RHELPLAN-141963
Testing: Tested by QE
This refers to the desired (scaled) frequency, which is called
user_tsc_khz in the rest of the file.
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
commit 866faa0e99083ee93d04d3c37065cf8dbfc51a34
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date: Mon Jan 23 17:24:19 2023 -0300
KVM: x86: rewrite handling of scaled TSC for kvmclock
commit 78db6a5037965429c04d708281f35a6e5562d31b
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2152838
Testing: Tested by QE
JIRA: https://issues.redhat.com/browse/RHELPLAN-141963
This is the same as before:
kvm_scale_tsc(tgt_tsc_khz)
= tgt_tsc_khz * ratio
= tgt_tsc_khz * user_tsc_khz / tsc_khz (see set_tsc_khz)
= user_tsc_khz (see kvm_guest_time_update)
= vcpu->arch.virtual_tsc_khz (see kvm_set_tsc_khz)
However, computing it through kvm_scale_tsc will make it possible
to include the NTP correction in tgt_tsc_khz.
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
commit bde6eebb5708ecd38db0023e657d38058e0d962f
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date: Wed Jan 25 16:07:18 2023 -0300
KVM: x86: add bit to indicate correct tsc_shift
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2152838
Testing: Tested by QE
Upstream Status: RHEL7 only
JIRA: https://issues.redhat.com/browse/RHELPLAN-141963
This changeset is unique to RHEL-7 since it was decided
it is not necessary upstream:
"I don't think it's justifiable to further complicate the userspace API for a
bug that's been fixed six years ago. I'd be very surprised if any combination
of modern upstream {QEMU,kernel} is going to do a successful migration from
such an old {QEMU,kernel}. RHEL/CentOS are able to do so because *specific
pairs* have been tested, but as far as upstream is concerned this adds
complexity that absolutely no one will use."
Before commit 78db6a5037965429c04d708281f35a6e5562d31b,
kvm_guest_time_update() would use vcpu->virtual_tsc_khz to calculate
tsc_shift value in the vcpus pvclock structure written to guest memory.
For those kernels, if vcpu->virtual_tsc_khz != tsc_khz (which can be the
case when guest state is restored via migration, or if tsc-khz option is
passed to QEMU), and TSC scaling is not enabled (which happens if the
difference between the frequency requested via KVM_SET_TSC_KHZ and the
host TSC KHZ is smaller than 250ppm), then there can be a difference
between what KVM_GET_CLOCK would return and what the guest reads as
kvmclock value.
When KVM_SET_CLOCK'ing what is read with KVM_GET_CLOCK, the
guest can observe a forward or backwards time jump.
Advertise to userspace that current kernel contains
this fix, so QEMU can workaround the problem by reading
pvclock via guest memory directly otherwise.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
commit 55a81001d2c4927795b36be55f54675f325c9ef2
Author: Davide Caratti <dcaratti@redhat.com>
Date: Wed Aug 9 15:22:14 2023 +0200
net/sched: cls_route: No longer copy tcf_result on update to avoid use-after-free
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2228703
CVE: CVE-2023-4128
Upstream Status: net.git commit b80b829e9e2c
commit b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8
Author: valis <sec@valis.email>
Date: Sat Jul 29 08:32:02 2023 -0400
net/sched: cls_route: No longer copy tcf_result on update to avoid use-after-free
When route4_change() is called on an existing filter, the whole
tcf_result struct is always copied into the new instance of the filter.
This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the
success path, decreasing filter_cnt of the still referenced class
and allowing it to be deleted, leading to a use-after-free.
Fix this by no longer copying the tcf_result struct from the old filter.
Fixes: 1109c00547fc ("net: sched: RCU cls_route")
Reported-by: valis <sec@valis.email>
Reported-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
Signed-off-by: valis <sec@valis.email>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Victor Nogueira <victor@mojatatu.com>
Reviewed-by: Pedro Tammela <pctammela@mojatatu.com>
Reviewed-by: M A Ramdhan <ramdhan@starlabs.sg>
Link: https://lore.kernel.org/r/20230729123202.72406-4-jhs@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
commit 820985c32b9616c7e793206ef8f8aff7c5ccfc8b
Author: Davide Caratti <dcaratti@redhat.com>
Date: Wed Aug 9 15:22:15 2023 +0200
net/sched: cls_fw: No longer copy tcf_result on update to avoid use-after-free
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2228703
CVE: CVE-2023-4128
Upstream Status: net.git commit 76e42ae83199
Conflicts:
- net/sched/cls_fw.c: context mismatch because of missing upstream commit
a51486266c3b ("net: sched: remove NET_CLS_IND config option")
commit 76e42ae831991c828cffa8c37736ebfb831ad5ec
Author: valis <sec@valis.email>
Date: Sat Jul 29 08:32:01 2023 -0400
net/sched: cls_fw: No longer copy tcf_result on update to avoid use-after-free
When fw_change() is called on an existing filter, the whole
tcf_result struct is always copied into the new instance of the filter.
This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the
success path, decreasing filter_cnt of the still referenced class
and allowing it to be deleted, leading to a use-after-free.
Fix this by no longer copying the tcf_result struct from the old filter.
Fixes: e35a8ee5993b ("net: sched: fw use RCU")
Reported-by: valis <sec@valis.email>
Reported-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
Signed-off-by: valis <sec@valis.email>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Victor Nogueira <victor@mojatatu.com>
Reviewed-by: Pedro Tammela <pctammela@mojatatu.com>
Reviewed-by: M A Ramdhan <ramdhan@starlabs.sg>
Link: https://lore.kernel.org/r/20230729123202.72406-3-jhs@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
commit 86b6be644c207dd3f4b3ecf4975a771608f0cece
Author: Davide Caratti <dcaratti@redhat.com>
Date: Wed Aug 9 15:23:37 2023 +0200
net/sched: cls_u32: No longer copy tcf_result on update to avoid use-after-free
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2228703
CVE: CVE-2023-4128
Upstream Status: net.git commit 3044b16e7c6f
commit 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81
Author: valis <sec@valis.email>
Date: Sat Jul 29 08:32:00 2023 -0400
net/sched: cls_u32: No longer copy tcf_result on update to avoid use-after-free
When u32_change() is called on an existing filter, the whole
tcf_result struct is always copied into the new instance of the filter.
This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the
success path, decreasing filter_cnt of the still referenced class
and allowing it to be deleted, leading to a use-after-free.
Fix this by no longer copying the tcf_result struct from the old filter.
Fixes: de5df63228fc ("net: sched: cls_u32 changes to knode must appear atomic to readers")
Reported-by: valis <sec@valis.email>
Reported-by: M A Ramdhan <ramdhan@starlabs.sg>
Signed-off-by: valis <sec@valis.email>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Victor Nogueira <victor@mojatatu.com>
Reviewed-by: Pedro Tammela <pctammela@mojatatu.com>
Reviewed-by: M A Ramdhan <ramdhan@starlabs.sg>
Link: https://lore.kernel.org/r/20230729123202.72406-2-jhs@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: Ryan Sullivan <rysulliv@redhat.com>
---
net/sched/cls_fw.c | 1 -
net/sched/cls_route.c | 1 -
net/sched/cls_u32.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/net/sched/cls_fw.c b/net/sched/cls_fw.c
index e05043266620..57563d1bf7a0 100644
--- a/net/sched/cls_fw.c
+++ b/net/sched/cls_fw.c
@@ -274,7 +274,6 @@ static int fw_change(struct net *net, struct sk_buff *in_skb,
return -ENOBUFS;
fnew->id = f->id;
- fnew->res = f->res;
#ifdef CONFIG_NET_CLS_IND
fnew->ifindex = f->ifindex;
#endif /* CONFIG_NET_CLS_IND */
diff --git a/net/sched/cls_route.c b/net/sched/cls_route.c
index d97c5bcdfa43..0bd48bd0bf9b 100644
--- a/net/sched/cls_route.c
+++ b/net/sched/cls_route.c
@@ -501,7 +501,6 @@ static int route4_change(struct net *net, struct sk_buff *in_skb,
if (fold) {
f->id = fold->id;
f->iif = fold->iif;
- f->res = fold->res;
f->handle = fold->handle;
f->tp = fold->tp;
diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index cc9398e10451..73e97f73447a 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -864,7 +864,6 @@ static struct tc_u_knode *u32_init_knode(struct tcf_proto *tp,
new->ifindex = n->ifindex;
#endif
new->fshift = n->fshift;
- new->res = n->res;
new->flags = n->flags;
RCU_INIT_POINTER(new->ht_down, n->ht_down);
--
2.41.0