[LTS 8.8 RT] CVE-2023-4206, CVE-2023-4207, CVE-2023-4208 #157
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-6647 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-6654 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-6661 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]>
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.8 RT]
CVE-2023-4206 VULN-6647
CVE-2023-4207 VULN-6654
CVE-2023-4208 VULN-6661
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.8 RT from the configuration standpoint.
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 8.8 RT version.
Unrelated to the
tcf_resultissue, it may be worth considering the retirement of thetcindexfilter in LTS 8.8 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.8 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: 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 (including tests skipped during execution)
android,bpf,breakpoints,capabilities,cgroup,core,cpu-hotplug,cpufreq,drivers/net/bonding,drivers/net/team,efivarfs,exec,filesystems,firmware,fpu,ftrace,futex,gpio,intel_pstate,ipc,kcmp,kvm,lib,livepatch,membarrier,memfd,memory-hotplug,mount,mqueue,net,net/forwarding,net/mptcp,netfilter,nsfs,proc,pstore,ptrace,rseq,rtc,sgx,sigaltstack,size,splice,static_keys,sync,sysctl,tc-testing,tdx,timens,timers,tpm2,user,vm,x86,zramReference
Two test runs were conducted on the reference kernel.
kselftests–mix–ciqlts8_8-rt–run1.log
kselftests–mix–ciqlts8_8-rt–run2.log
Patch
Two test runs were conducted on the patched kernel.
kselftests–mix–ciqlts8_8-rt-CVE-2023-4206.4207.4208–run1.log
kselftests–mix–ciqlts8_8-rt-CVE-2023-4206.4207.4208–run2.log
Comparison
Of the differing results the tests
bpf:test_tcpnotify_user,net/mptcp:simult_flows.sh,net:gro.sh,netfilter:nft_queue.shwere known to give inconsistent results before.The
net:reuseport_addr_any.shtest was known to be always failing before and now it shows inconsistent results for the reference batch - added to the list of flappy tests.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_8-rt–run1.log
kselftests-net-forwarding–src–ciqlts8_8-rt–run2.log
kselftests-net-forwarding–src–ciqlts8_8-rt–run3.log
Patch
A single test run was conducted on the patched kernel.
kselftests-net-forwarding–src–ciqlts8_8-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 (37 / 54). 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.