[LTS 9.2] CVE-2023-4206, CVE-2023-4207, CVE-2023-4208 #158
Conversation
…fter-free jira VULN-6656 cve CVE-2023-4207 commit-author valis <[email protected]> commit 76e42ae 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: e35a8ee ("net: sched: fw use RCU") Reported-by: valis <[email protected]> Reported-by: Bing-Jhong Billy Jheng <[email protected]> Signed-off-by: valis <[email protected]> Signed-off-by: Jamal Hadi Salim <[email protected]> Reviewed-by: Victor Nogueira <[email protected]> Reviewed-by: Pedro Tammela <[email protected]> Reviewed-by: M A Ramdhan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 76e42ae) Signed-off-by: Marcin Wcisło <[email protected]>
…after-free jira VULN-6663 cve CVE-2023-4208 commit-author valis <[email protected]> commit 3044b16 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: de5df63 ("net: sched: cls_u32 changes to knode must appear atomic to readers") Reported-by: valis <[email protected]> Reported-by: M A Ramdhan <[email protected]> Signed-off-by: valis <[email protected]> Signed-off-by: Jamal Hadi Salim <[email protected]> Reviewed-by: Victor Nogueira <[email protected]> Reviewed-by: Pedro Tammela <[email protected]> Reviewed-by: M A Ramdhan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 3044b16) Signed-off-by: Marcin Wcisło <[email protected]>
There was a problem hiding this comment.
I agree with the logic that CVE-2023-4206 isn't applicable due to the config. But I would have been ok with applying the change anyway since its so simple.
🥌
There was a problem hiding this comment.
I agree with the logic that GHSA-r8pm-459q-x6hw isn't applicable due to the config. But I would have been ok with applying the change anyway since its so simple.
I agree I assume that its because it was so simple because RHEL did fix it in:
https://access.redhat.com/errata/RHSA-2023:7370
kernel: net/sched: multiple vulnerabilities (CVE-2023-3609, CVE-2023-4128, CVE-2023-4206, CVE-2023-4207, CVE-2023-4208)
kernel-5.14.0-284.40.1.el9_2.src.rpm
They also showed that they fixed it in 9.3 as well.
But still in 9.4 that option is not set.
I may still get the fix applied but I'll task it to some people that are working on the edges of the kernel since its in "dead code."
@bmastbergen and @pvts-mat I appreciate you both digging in to validate CVE-2023-4206
[LTS 9.2]
CVE-2023-4206 VULN-6649
CVE-2023-4207 VULN-6656
CVE-2023-4208 VULN-6663
Problem
The PR addresses a series of related CVEs, which were once listed under a single CVE-2023-4128. From https://lore.kernel.org/netdev/[email protected]/:
Each CVE is related to a different classifier:
Analysis and solution
Official fixes
The official fixes for each of the vulnerabilities are as follows:
Applicability
The CVE-2023-4206 is not applicable to the LTS 9.2 from the configuration standpoint, as the
route4classifier is disabled by default. Other CVEs are applicable.Analysis
For the discussion of the validity of a fix based on simply ignoring a certain field while copying a data structure where the actual copy may be expected see analysis for LTS 8.6 RT Pull Request - it was not repeated for the LTS 9.2 version. (Note that the doubts raised there about keeping
tcindexfilter don't apply to this version as this filter is disabled in LTS 9.2 configuration.)kABI check
Boot test: passed
boot-test.log
Kselftests: passed relative
Methodology
A mix of
kernel-selftests-internaland source-compiled tests were used:kernel-selftests-internal:bpftests, except:bpf:test_kmod.sh: takes very long time to finish and always fails anyway,bpf:test_progs: unstable, can crash the machine,bpf:test_progs-no_alu32: unstable, can crash the machine.Coverage
bpf,breakpoints,capabilities,clone3,core,cpu-hotplug,cpufreq,drivers/dma-buf,drivers/net/bonding,drivers/net/team,efivarfs,filesystems,filesystems/binderfs,filesystems/epoll,firmware,fpu,ftrace,futex,gpio,intel_pstate,ipc,ir,kcmp,kvm,landlock,lib,livepatch,membarrier,memfd,memory-hotplug,mincore,mount,mqueue,nci,net,net/forwarding,net/mptcp,netfilter,nsfs,openat2,pid_namespace,pidfd,pstore,ptrace,rlimits,rseq,rtc,seccomp,sgx,sigaltstack,size,splice,static_keys,sync,syscall_user_dispatch,sysctl,tc-testing,tdx,timens,timers,tmpfs,tpm2,user,vDSO,vm,x86,zramReference
Three test runs were conducted on the reference kernel.
kselftests–mix–ciqlts9_2–run1.log
kselftests–mix–ciqlts9_2–run2.log
kselftests–mix–ciqlts9_2–run3.log
Patch
Two test runs were conducted on the patched kernel.
kselftests–mix–ciqlts9_2-CVE-2023-4206.4207.4208–run1.log
kselftests–mix–ciqlts9_2-CVE-2023-4206.4207.4208–run2.log
Comparison
Of the differing results the tests
net:gro.sh,net:txtimestamp.sh,rtc:rtctestwere known to give inconsistent results before.The
timers:raw_skewtest was skipped in the reference test suite due to some external interferenceKselftests (networking): passed relative
Methodology
In general kselftests all the
net/forwardingtests fail (really should be skipped) because of the missing tool dependenciesBecause the patch deals with networking specifically, an additional batch of tests was carried out after solving the test requirements issues.
The
tools/testing/selftests/net/forwarding/forwarding.configfile used was created directly from thetools/testing/selftests/net/forwarding/forwarding.config.sample.Reference
Three test runs were conducted on the reference kernel.
kselftests-net-forwarding–src–ciqlts9_2–run1.log
kselftests-net-forwarding–src–ciqlts9_2–run2.log
kselftests-net-forwarding–src–ciqlts9_2–run3.log
Patch
A single test run was conducted on the patched kernel.
kselftests-net-forwarding–src–ciqlts9_2-CVE-2023-4206.4207.4208–run1.log
Comparison and discussion
Results for the reference and patched kernel are the same.
The list of
net/forwardingtests performed is not exhaustive (66 / 92). Thenet/forwarding:sch_ets.shtest executed right afternet/forwarding:router_vid_1.shcauses the machine to hang for more than 10 minutes and the used testing framework interrupts the test suite.The fix for the problem was deferred to another CVE for the sake of patching efficiency.