[LTS 8.6 RT] CVE-2023-4206, CVE-2023-4207, CVE-2023-4208 #155
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…e-after-free jira VULN-6645 cve CVE-2023-4206 commit-author valis <[email protected]> commit b80b829 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: 1109c00 ("net: sched: RCU cls_route") 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 b80b829) Signed-off-by: Marcin Wcisło <[email protected]>
…fter-free jira VULN-6652 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-6659 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]>
This was referenced Mar 12, 2025
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[LTS 8.6 RT]
CVE-2023-4206 VULN-6645
CVE-2023-4207 VULN-6652
CVE-2023-4208 VULN-6659
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
Each change is applicable to the LTS 8.6 RT from the configuration standpoint.
Analysis
The official fix is very straightforward yet it begs the question: isn't the
tcf_result-type struct needed in the new instance of the appropriate filter object? Doesn't the erasure ofresfield break some expectation some code using thechangefunction may have, if the changing ofreswasn't requested?While the attempts to answer this question based on the encoded logic alone were inconclusive (no counter examples found but also too little expertise in this codebase to give definite affirmative answer), some support for this solution can be provided by comparing the modified classifiers to others.
The kernel provides 11 classifiers in total, based on modules implementing
tcf_proto_ops:Each classifier has an associated filter struct. Two of these filter structs (
cgroup,flow) don't containtcf_result-type field and thus cannot be compared against. Three classifiers are objects of the evaluation -fw,route,u32. This leaves 6 classifiers to check for how they operate on thetcf_resultfields in their respectivechangefunction:basic,bpf,flower,matchall,rsvp,tcindex.Analysis of the filter functions of these classifiers shows that no
tcf_resultis copied on the creation of new filter struct instance. The single exception istcindex: copying oftcf_resultstruct to the newly created filter struct does seem to be taking place in a rather convoluted way. (The**argin tcindex_change is passed asrto tcindex_set_parms. There the copy ofr->resis assigned to the local variablecrin caserwasn't null. Then it's assigned back tor->res, except this timermay not be the same as provided in the argument, but also&new_filter_result. In that case a new filter structfis created and receives the copy oftcf_result.) The error condition from CVEs doesn't seem to occur in this case though, as there is notcf_unbind_filtercall messing with the reference counters. This supports the thesis that copyingtcf_resultinto the newly created filter instance is preferable but perhaps not required and can be foregone when it's causing problems.Unrelated to the
tcf_resultissue, it may be worth considering the retirement of thetcindexfilter in LTS 8.6 RT, as it was done in the mainline kernel for security reasons on 2023-02-16:(Syzkaller = Google's fuzzing framework)
Retiring
tcindexfrom mainline kernel is unfortunate, because it leaves LTS 8.6 RT not only with rich source of vulnerabilities, as the commit's message suggests, but a silent source, without any CVEs nor patches made for them by kernel.org in the future.kABI check: omitted (unstable ABI of RT kernels)
Boot test: passed
boot-test.log
Kselftests (general): passed relative
Methodology
Source-compiled (
e1a9851e6068a6ef800ec6b2b48a7c243882ed06) kselftests suite was used.Coverage (including tests skipped during execution)
android,breakpoints,capabilities,core,cpu-hotplug,cpufreq,efivarfs,exec,filesystems,firmware,fpu,ftrace,futex,gpio,intel_pstate,ipc,kcmp,kvm,lib,livepatch,membarrier,memfd,memory-hotplug,mount,net,net/forwarding,net/mptcp,netfilter,nsfs,proc,pstore,ptrace,rseq,rtc,sgx,sigaltstack,size,splice,static_keys,sync,sysctl,tc-testing,timens,timers,tpm2,user,vm,x86,zramReference
Three test runs were conducted on the reference kernel.
kselftests–src–ciqlts8_6-rt–run1.log
kselftests–src–ciqlts8_6-rt–run2.log
kselftests–src–ciqlts8_6-rt–run3.log
Patch
Two test runs were conducted on the patched kernel.
kselftests–src–ciqlts8_6-rt-CVE-2023-4206.4207.4208–run1.log
kselftests–src–ciqlts8_6-rt-CVE-2023-4206.4207.4208–run2.log
Comparison
All the differing results are for tests known before to give inconsistent results.
Kselftests (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–ciqlts8_6-rt–run1.log
kselftests-net-forwarding–src–ciqlts8_6-rt–run2.log
kselftests-net-forwarding–src–ciqlts8_6-rt–run3.log
Patch
A single test run was conducted on the patched kernel.
kselftests-net-forwarding–src–ciqlts8_6-rt-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 (36 / 53). 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.