diff --git a/SOURCES/CVE-2023-3611.patch b/SOURCES/CVE-2023-3611.patch new file mode 100644 index 0000000..3eb5236 --- /dev/null +++ b/SOURCES/CVE-2023-3611.patch @@ -0,0 +1,225 @@ +From d899fb6f8a4b6370576e3a009e959bc98ee03c16 Mon Sep 17 00:00:00 2001 +From: Ryan Sullivan +Date: Mon, 16 Oct 2023 14:08:36 -0400 +Subject: [KPATCH CVE-2023-3611] kpatch fixes for CVE-2023-3611 + +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/60 +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 +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 + Signed-off-by: Paolo Bonzini + Signed-off-by: Marcelo Tosatti + +commit 866faa0e99083ee93d04d3c37065cf8dbfc51a34 +Author: Marcelo Tosatti +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 + Signed-off-by: Paolo Bonzini + Signed-off-by: Marcelo Tosatti + +commit bde6eebb5708ecd38db0023e657d38058e0d962f +Author: Marcelo Tosatti +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 + +commit 9dbd3713d82f45c9781f2dc6dd49dc3ee07ba980 +Author: Davide Caratti +Date: Tue Aug 8 12:55:43 2023 +0200 + + net/sched: sch_qfq: account for stab overhead in qfq_enqueue + + Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2225555 + CVE: CVE-2023-3611 + Upstream Status: net.git commit 3e337087c3b5 + Conflicts: + - we don't have QFQ_MAX_LMAX defined in rhel-7 because of + missing upstream commit 25369891fcef ("net/sched: sch_qfq: + refactor parsing of netlink parameters"): use its value in + the test inside qfq_change_agg() + + commit 3e337087c3b5805fe0b8a46ba622a962880b5d64 + Author: Pedro Tammela + Date: Tue Jul 11 18:01:02 2023 -0300 + + net/sched: sch_qfq: account for stab overhead in qfq_enqueue + + Lion says: + ------- + In the QFQ scheduler a similar issue to CVE-2023-31436 + persists. + + Consider the following code in net/sched/sch_qfq.c: + + static int qfq_enqueue(struct sk_buff *skb, struct Qdisc *sch, + struct sk_buff **to_free) + { + unsigned int len = qdisc_pkt_len(skb), gso_segs; + + // ... + + if (unlikely(cl->agg->lmax < len)) { + pr_debug("qfq: increasing maxpkt from %u to %u for class %u", + cl->agg->lmax, len, cl->common.classid); + err = qfq_change_agg(sch, cl, cl->agg->class_weight, len); + if (err) { + cl->qstats.drops++; + return qdisc_drop(skb, sch, to_free); + } + + // ... + + } + + Similarly to CVE-2023-31436, "lmax" is increased without any bounds + checks according to the packet length "len". Usually this would not + impose a problem because packet sizes are naturally limited. + + This is however not the actual packet length, rather the + "qdisc_pkt_len(skb)" which might apply size transformations according to + "struct qdisc_size_table" as created by "qdisc_get_stab()" in + net/sched/sch_api.c if the TCA_STAB option was set when modifying the qdisc. + + A user may choose virtually any size using such a table. + + As a result the same issue as in CVE-2023-31436 can occur, allowing heap + out-of-bounds read / writes in the kmalloc-8192 cache. + ------- + + We can create the issue with the following commands: + + tc qdisc add dev $DEV root handle 1: stab mtu 2048 tsize 512 mpu 0 \ + overhead 999999999 linklayer ethernet qfq + tc class add dev $DEV parent 1: classid 1:1 htb rate 6mbit burst 15k + tc filter add dev $DEV parent 1: matchall classid 1:1 + ping -I $DEV 1.1.1.2 + + This is caused by incorrectly assuming that qdisc_pkt_len() returns a + length within the QFQ_MIN_LMAX < len < QFQ_MAX_LMAX. + + Fixes: 462dbc9101ac ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost") + Reported-by: Lion + Reviewed-by: Eric Dumazet + Signed-off-by: Jamal Hadi Salim + Signed-off-by: Pedro Tammela + Reviewed-by: Simon Horman + Signed-off-by: Paolo Abeni + + Signed-off-by: Davide Caratti + +Signed-off-by: Ryan Sullivan +--- + net/sched/sch_qfq.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c +index a36b3ec3271a..ca8c79456c80 100644 +--- a/net/sched/sch_qfq.c ++++ b/net/sched/sch_qfq.c +@@ -387,8 +387,13 @@ static int qfq_change_agg(struct Qdisc *sch, struct qfq_class *cl, u32 weight, + u32 lmax) + { + struct qfq_sched *q = qdisc_priv(sch); +- struct qfq_aggregate *new_agg = qfq_find_agg(q, lmax, weight); ++ struct qfq_aggregate *new_agg; + ++ /* 'lmax' can range from [QFQ_MIN_LMAX, pktlen + stab overhead] */ ++ if (lmax > (1UL << QFQ_MTU_SHIFT)) ++ return -EINVAL; ++ ++ new_agg = qfq_find_agg(q, lmax, weight); + if (new_agg == NULL) { /* create new aggregate */ + new_agg = kzalloc(sizeof(*new_agg), GFP_ATOMIC); + if (new_agg == NULL) +-- +2.41.0 + + diff --git a/SOURCES/CVE-2023-3776.patch b/SOURCES/CVE-2023-3776.patch new file mode 100644 index 0000000..406821f --- /dev/null +++ b/SOURCES/CVE-2023-3776.patch @@ -0,0 +1,189 @@ +From 8a3e286f2ff1f83ffd645cbad1cb49f80ab2ab00 Mon Sep 17 00:00:00 2001 +From: Ryan Sullivan +Date: Tue, 17 Oct 2023 13:28:46 -0400 +Subject: [KPATCH CVE-2023-3776] kpatch fixes for CVE-2023-3776 + +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/61 +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 +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 + Signed-off-by: Paolo Bonzini + Signed-off-by: Marcelo Tosatti + +commit 866faa0e99083ee93d04d3c37065cf8dbfc51a34 +Author: Marcelo Tosatti +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 + Signed-off-by: Paolo Bonzini + Signed-off-by: Marcelo Tosatti + +commit bde6eebb5708ecd38db0023e657d38058e0d962f +Author: Marcelo Tosatti +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 + +commit 373ed8339c956ce1d9049737bab779f143fc1267 +Author: Davide Caratti +Date: Tue Aug 8 11:57:51 2023 +0200 + + net/sched: cls_fw: Fix improper refcount update leads to use-after-free + + Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2225639 + CVE: CVE-2023-3776 + Upstream Status: net.git commit 0323bce598ee + Conflicts: + - net/sched/cls_fw.c: context mismatch because of missing backport + of upstream commit a51486266c3b ("net: sched: remove NET_CLS_IND + config option") + + commit 0323bce598eea038714f941ce2b22541c46d488f + Author: M A Ramdhan + Date: Wed Jul 5 12:15:30 2023 -0400 + + net/sched: cls_fw: Fix improper refcount update leads to use-after-free + + In the event of a failure in tcf_change_indev(), fw_set_parms() will + immediately return an error after incrementing or decrementing + reference counter in tcf_bind_filter(). If attacker can control + reference counter to zero and make reference freed, leading to + use after free. + + In order to prevent this, move the point of possible failure above the + point where the TC_FW_CLASSID is handled. + + Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") + Reported-by: M A Ramdhan + Signed-off-by: M A Ramdhan + Acked-by: Jamal Hadi Salim + Reviewed-by: Pedro Tammela + Message-ID: <20230705161530.52003-1-ramdhan@starlabs.sg> + Signed-off-by: Jakub Kicinski + + Signed-off-by: Davide Caratti + +Signed-off-by: Ryan Sullivan +--- + net/sched/cls_fw.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +diff --git a/net/sched/cls_fw.c b/net/sched/cls_fw.c +index e05043266620..3427222f8e60 100644 +--- a/net/sched/cls_fw.c ++++ b/net/sched/cls_fw.c +@@ -218,11 +218,6 @@ static int fw_set_parms(struct net *net, struct tcf_proto *tp, + if (err < 0) + return err; + +- if (tb[TCA_FW_CLASSID]) { +- f->res.classid = nla_get_u32(tb[TCA_FW_CLASSID]); +- tcf_bind_filter(tp, &f->res, base); +- } +- + #ifdef CONFIG_NET_CLS_IND + if (tb[TCA_FW_INDEV]) { + int ret; +@@ -241,6 +236,11 @@ static int fw_set_parms(struct net *net, struct tcf_proto *tp, + } else if (head->mask != 0xFFFFFFFF) + return err; + ++ if (tb[TCA_FW_CLASSID]) { ++ f->res.classid = nla_get_u32(tb[TCA_FW_CLASSID]); ++ tcf_bind_filter(tp, &f->res, base); ++ } ++ + return 0; + } + +-- +2.41.0 + + diff --git a/SOURCES/CVE-2023-4128.patch b/SOURCES/CVE-2023-4128.patch new file mode 100644 index 0000000..66cccd8 --- /dev/null +++ b/SOURCES/CVE-2023-4128.patch @@ -0,0 +1,280 @@ +From d755c1f10a580e972fafb7bebf24378b5b830b98 Mon Sep 17 00:00:00 2001 +From: Ryan Sullivan +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 +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 + Signed-off-by: Paolo Bonzini + Signed-off-by: Marcelo Tosatti + +commit 866faa0e99083ee93d04d3c37065cf8dbfc51a34 +Author: Marcelo Tosatti +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 + Signed-off-by: Paolo Bonzini + Signed-off-by: Marcelo Tosatti + +commit bde6eebb5708ecd38db0023e657d38058e0d962f +Author: Marcelo Tosatti +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 + +commit 55a81001d2c4927795b36be55f54675f325c9ef2 +Author: Davide Caratti +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 + 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 + Reported-by: Bing-Jhong Billy Jheng + Signed-off-by: valis + Signed-off-by: Jamal Hadi Salim + Reviewed-by: Victor Nogueira + Reviewed-by: Pedro Tammela + Reviewed-by: M A Ramdhan + Link: https://lore.kernel.org/r/20230729123202.72406-4-jhs@mojatatu.com + Signed-off-by: Jakub Kicinski + + Signed-off-by: Davide Caratti + +commit 820985c32b9616c7e793206ef8f8aff7c5ccfc8b +Author: Davide Caratti +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 + 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 + Reported-by: Bing-Jhong Billy Jheng + Signed-off-by: valis + Signed-off-by: Jamal Hadi Salim + Reviewed-by: Victor Nogueira + Reviewed-by: Pedro Tammela + Reviewed-by: M A Ramdhan + Link: https://lore.kernel.org/r/20230729123202.72406-3-jhs@mojatatu.com + Signed-off-by: Jakub Kicinski + + Signed-off-by: Davide Caratti + +commit 86b6be644c207dd3f4b3ecf4975a771608f0cece +Author: Davide Caratti +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 + 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 + Reported-by: M A Ramdhan + Signed-off-by: valis + Signed-off-by: Jamal Hadi Salim + Reviewed-by: Victor Nogueira + Reviewed-by: Pedro Tammela + Reviewed-by: M A Ramdhan + Link: https://lore.kernel.org/r/20230729123202.72406-2-jhs@mojatatu.com + Signed-off-by: Jakub Kicinski + + Signed-off-by: Davide Caratti + +Signed-off-by: Ryan Sullivan +--- + 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 + + diff --git a/SPECS/kpatch-patch.spec b/SPECS/kpatch-patch.spec index d18bf32..a3d4574 100644 --- a/SPECS/kpatch-patch.spec +++ b/SPECS/kpatch-patch.spec @@ -6,7 +6,7 @@ %define kernel_ver 3.10.0-1160.99.1.el7 %define kpatch_ver 0.9.2 %define rpm_ver 1 -%define rpm_rel 1 +%define rpm_rel 2 %if !%{empty_package} # Patch sources below. DO NOT REMOVE THIS LINE. @@ -19,6 +19,15 @@ Source101: CVE-2023-35001.patch # # https://bugzilla.redhat.com/2225510 Source102: CVE-2023-3609.patch +# +# https://issues.redhat.com/browse/RHEL-9077 +Source103: CVE-2023-3611.patch +# +# https://issues.redhat.com/browse/RHEL-9208 +Source104: CVE-2023-3776.patch +# +# https://issues.redhat.com/browse/RHEL-9016 +Source105: CVE-2023-4128.patch # End of patch sources. DO NOT REMOVE THIS LINE. %endif @@ -153,6 +162,11 @@ It is only a method to subscribe to the kpatch stream for kernel-%{kernel_ver}. %endif %changelog +* Mon Nov 13 2023 Yannick Cote [1-2.el7] +- kernel: net/sched: Use-after-free vulnerabilities in the net/sched classifiers: cls_fw, cls_u32 and cls_route [RHEL-9016] {CVE-2023-4128} +- kernel: net/sched: cls_fw component can be exploited as result of failure in tcf_change_indev function [RHEL-9208] {CVE-2023-3776} +- kernel: net/sched: sch_qfq component can be exploited if in qfq_change_agg function happens qfq_enqueue overhead [RHEL-9077] {CVE-2023-3611} + * Tue Sep 26 2023 Yannick Cote [1-1.el7] - kernel: net/sched: cls_u32 component reference counter leak if tcf_change_indev() fails [2225510] {CVE-2023-3609} - kernel: nf_tables: stack-out-of-bounds-read in nft_byteorder_eval() [2221747] {CVE-2023-35001}