[LTS 9.2] netfilter: CVE-2022-{48641, 49917, 49918}, CVE-2023-{3777, 4015, 4244, 5197, 52620, 52923, 52924, 53549, 53635, 7192} #668
Conversation
|
@pvts-mat I know this is still in draft, but wanted to upload the output from our upstream bug and cve checker script. Most of the |
|
As you mentioned in the PR summary and we've discussed in slack, for the moment this PR seems large enough and pulling in the bugfixes above would only make it bigger. I'm ok with kicking the bugfixes down the road to a future PR. |
Thanks, that's exactly why I put it out there instead of drafting it locally, there's a lot to look into here, I wanted to have the discussion rolling. Let me address the logs, I'll start with
Here's the detailed breakdown: |
|
Yep, that one is wrong in the commit, and I have it correct in the PR so it must have been a cherry-picking mistake. |
pvts-mat
force-pushed
the
ciqlts9_2-CVE-batch-10
branch
from
2919917 to
520390b
Compare
|
All the fixes reported are addressed in the
I'll explain the Rows
Then there are the 6da5f1b and 8d1c918 fixes for 73db1b8 mentioned in the script's log. I guess the SHA codes are truncated to less than 7 characters in the searches, because the "Fixes" commit referenced there isn't 73db1b8 actually, but 73db1b5. Funnily enough it's also |
With respect to this since it is in our kernel but not upstream kernel but is upstream to CIQ its in the CentOS-Stream that we maintain a copy of in our tree. Maybe we need to make add some additional logic to see if its in our tree. We have some examples in commits for CIQ-6.12.y branch where we pull from |
|
These two need reordered
Order should be: |
Hmm, it seems unlikely that 2cdaa3e( Indeed the 47d4b36( Perhaps |
There was a problem hiding this comment.
This file is wild at this point it all seems the same, but the diffs between our and upstream make this super hard to read.
No I'm wrong I got mixed up, i missed this part of a9e9413
Let me think about and get back to you on the second part its been several hours looking through this. |
-Fixed relocation failure observed on [1] -Fixed spurious (and massive) added or deleted code blocks appearing in the output for rejected hunks, encountered with [1] -Fixed N value passed to --fuzzy not getting honored correctly, causing more fuzzing to occur than desired -Fixed too few context lines in the output which hurt readability; now there are more context lines in the output [1] #668
Apologies for the delay, yes despite it being a clean cherry-pick since we're missing 0fabd2aa199faeb8754aee94658f2c48ccb2c8c3(kernel-mainline) its probably worth mentioning because they code never moved in the first place. We're also not referencing that code anywhere, So yes lets add the |
pvts-mat
force-pushed
the
ciqlts9_2-CVE-batch-10
branch
2 times, most recently
from
b413376 to
740e770
Compare
|
@PlaidCat So how about the "tagging policy"? Do we keep the CVE tags as they are? (I hope not). The issue is: how to cve-tag commits which do not address any specific CVE and which neither are bugfixes to any specific CVE nor they are prerequisites (or establishing those would be impractical and not even reflecting the workflow). |
In this sort of case feel free to change those to basically like what we did here:
is there more?? Let me know i'll process this.
I can make one but i'll need all the merges you're basing this off of and I can create a ticket. |
But that's not a subsystem sync. A subsystem sync has a specific codebase endpoint to achieve as a goal. Here no specific codebase revision was achieved, nor was it ever a goal, so both the version number - whatever is chosen - will be misleading as well as the implication of methodology. I was careful not to make the actual sync, which would be over 3x the volume of this merge. This is just a backport, but big one. A "wholesale backporting" if you like. I don't think it has a precedent in Rocky patching, or at least I didn't see it in the public PRs.
Please see the comment #668 (comment). |
In the case of this specific PR it's quite clear - the effort was driven by the CVE-2023-4244 fix, which has the associated jira ticket I was asking for a more general rule covering less clear-cut cases, like the next |
Maybe something like: That is a reference to the centos stream 9 merge commit that we are emulating. Just spitballing |
|
Commit is not a clean cherry pick due to missing |
Similar for |
Those are the commits no.
Notice the values in the
Also from the "Backporting strategy":
It should be added perhaps that in the case of clean picks from mainline the commits were equivalent to those in 9.4, so sourcecode-wise it made no difference whether it was mainline or 9.4 (so we're not doing some wild
I like this one. I would add this line even to those commits which do have |
I meant you should update the commit message to reflect that they are not clean cherry picks. At the moment we don't have a way to differentiate between multiple sources, so even if it's a clean cherry pick from 9.4 let's say, an upstream-diff mention should be added. You did so for other cherry picks. |
Ok, so the issue is the lack of |
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Pablo Neira Ayuso <[email protected]> commit 23185c6 Do not allow to insert elements from datapath to objects maps. Fixes: 8aeff92 ("netfilter: nf_tables: add stateful object reference to set elements") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Florian Westphal <[email protected]> (cherry picked from commit 23185c6) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Pablo Neira Ayuso <[email protected]> commit 2c9f029 Destroy work waits for the RCU grace period then it releases the objects with no mutex held. All releases objects follow this path for transactions, therefore, order is guaranteed and references to top-level objects in the hierarchy remain valid. However, netlink notifier might interfer with pending destroy work. rcu_barrier() is not correct because objects are not release via RCU callback. Flush destroy work before releasing objects from netlink notifier path. Fixes: d4bc827 ("netfilter: nf_tables: netlink notifier might race to release objects") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Florian Westphal <[email protected]> (cherry picked from commit 2c9f029) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Pablo Neira Ayuso <[email protected]> commit 7203443 Abort path is missing a synchronization point with GC transactions. Add GC sequence number hence any GC transaction losing race will be discarded. Fixes: 5f68718 ("netfilter: nf_tables: GC transaction API to avoid race with control plane") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Florian Westphal <[email protected]> (cherry picked from commit 7203443) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Pablo Neira Ayuso <[email protected]> commit 8357bc9 Use nf_tables_gc_list_lock spinlock, not nf_tables_destroy_list_lock to protect the gc list. Fixes: 5f68718 ("netfilter: nf_tables: GC transaction API to avoid race with control plane") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Florian Westphal <[email protected]> (cherry picked from commit 8357bc9) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Florian Westphal <[email protected]> commit 5e1be4c Several instances of pipapo_resize() don't propagate allocation failures, this causes a crash when fault injection is enabled for gfp_kernel slabs. Fixes: 3c4287f ("nf_tables: Add set type for arbitrary concatenation of ranges") Signed-off-by: Florian Westphal <[email protected]> Reviewed-by: Stefano Brivio <[email protected]> (cherry picked from commit 5e1be4c) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Florian Westphal <[email protected]> commit 8e51830 Don't queue more gc work, else we may queue the same elements multiple times. If an element is flagged as dead, this can mean that either the previous gc request was invalidated/discarded by a transaction or that the previous request is still pending in the system work queue. The latter will happen if the gc interval is set to a very low value, e.g. 1ms, and system work queue is backlogged. The sets refcount is 1 if no previous gc requeusts are queued, so add a helper for this and skip gc run if old requests are pending. Add a helper for this and skip the gc run in this case. Fixes: f6c383b ("netfilter: nf_tables: adapt set backend to use GC transaction API") Signed-off-by: Florian Westphal <[email protected]> Reviewed-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 8e51830) Signed-off-by: Marcin Wcisło <[email protected]>
…saction jira VULN-158866 subsystem-update netfilter: centos-stream-9 cfd9694 cve CVE-2023-52433 commit-author Pablo Neira Ayuso <[email protected]> commit 2ee52ae New elements in this transaction might expired before such transaction ends. Skip sync GC for such elements otherwise commit path might walk over an already released object. Once transaction is finished, async GC will collect such expired element. Fixes: f6c383b ("netfilter: nf_tables: adapt set backend to use GC transaction API") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Florian Westphal <[email protected]> (cherry picked from commit 2ee52ae) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-34732 subsystem-update netfilter: centos-stream-9 cfd9694 cve CVE-2023-5197 commit-author Pablo Neira Ayuso <[email protected]> commit f15f29f upstream-diff Used the cleanly applying 9.4 backport 29530d2 Chain binding only requires the rule addition/insertion command within the same transaction. Removal of rules from chain bindings within the same transaction makes no sense, userspace does not utilize this feature. Replace nft_chain_is_bound() check to nft_chain_binding() in rule deletion commands. Replace command implies a rule deletion, reject this command too. Rule flush command can also safely rely on this nft_chain_binding() check because unbound chains are not allowed since 62e1e94 ("netfilter: nf_tables: reject unbound chain set before commit phase"). Fixes: d0e2c7d ("netfilter: nf_tables: add NFT_CHAIN_BINDING") Reported-by: Kevin Rich <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit f15f29f) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Pablo Neira Ayuso <[email protected]> commit 4a9e12e pipapo needs to enqueue GC transactions for catchall elements through nft_trans_gc_queue_sync(). Add nft_trans_gc_catchall_sync() and nft_trans_gc_catchall_async() to handle GC transaction queueing accordingly. Fixes: 5f68718 ("netfilter: nf_tables: GC transaction API to avoid race with control plane") Fixes: f6c383b ("netfilter: nf_tables: adapt set backend to use GC transaction API") Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 4a9e12e) Signed-off-by: Marcin Wcisło <[email protected]>
…tion jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Pablo Neira Ayuso <[email protected]> commit 96b3330 rbtree GC does not modify the datastructure, instead it collects expired elements and it enqueues a GC transaction. Use a read spinlock instead to avoid data contention while GC worker is running. Fixes: f6c383b ("netfilter: nf_tables: adapt set backend to use GC transaction API") Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 96b3330) Signed-off-by: Marcin Wcisło <[email protected]>
…tion fails jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Pablo Neira Ayuso <[email protected]> commit 6d365ea nft_trans_gc_queue_sync() enqueues the GC transaction and it allocates a new one. If this allocation fails, then stop this GC sync run and retry later. Fixes: 5f68718 ("netfilter: nf_tables: GC transaction API to avoid race with control plane") Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 6d365ea) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Pablo Neira Ayuso <[email protected]> commit b079155 Skip GC run if iterator rewinds to the beginning with EAGAIN, otherwise GC might collect the same element more than once. Fixes: f6c383b ("netfilter: nf_tables: adapt set backend to use GC transaction API") Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit b079155) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Pablo Neira Ayuso <[email protected]> commit 23a3bfd Anonymous sets need to be populated once at creation and then they are bound to rule since 938154b ("netfilter: nf_tables: reject unbound anonymous set before commit phase"), otherwise transaction reports EINVAL. Userspace does not need to delete elements of anonymous sets that are not yet bound, reject this with EOPNOTSUPP. From flush command path, skip anonymous sets, they are expected to be bound already. Otherwise, EINVAL is hit at the end of this transaction for unbound sets. Fixes: 9651851 ("netfilter: add nftables") Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 23a3bfd) Signed-off-by: Marcin Wcisło <[email protected]>
…once jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Florian Westphal <[email protected]> commit c9bd265 nft -f -<<EOF add table ip t add table ip t { flags dormant; } add chain ip t c { type filter hook input priority 0; } add table ip t EOF Triggers a splat from nf core on next table delete because we lose track of right hook register state: WARNING: CPU: 2 PID: 1597 at net/netfilter/core.c:501 __nf_unregister_net_hook RIP: 0010:__nf_unregister_net_hook+0x41b/0x570 nf_unregister_net_hook+0xb4/0xf0 __nf_tables_unregister_hook+0x160/0x1d0 [..] The above should have table in *active* state, but in fact no hooks were registered. Reject on/off/on games rather than attempting to fix this. Fixes: 179d9ba ("netfilter: nf_tables: fix table flag updates") Reported-by: "Lee, Cherie-Anne" <[email protected]> Cc: Bing-Jhong Billy Jheng <[email protected]> Cc: [email protected] Signed-off-by: Florian Westphal <[email protected]> (cherry picked from commit c9bd265) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-598 subsystem-update netfilter: centos-stream-9 cfd9694 cve CVE-2023-52581 commit-author Florian Westphal <[email protected]> commit cf5000a When more than 255 elements expired we're supposed to switch to a new gc container structure. This never happens: u8 type will wrap before reaching the boundary and nft_trans_gc_space() always returns true. This means we recycle the initial gc container structure and lose track of the elements that came before. While at it, don't deref 'gc' after we've passed it to call_rcu. Fixes: 5f68718 ("netfilter: nf_tables: GC transaction API to avoid race with control plane") Reported-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Florian Westphal <[email protected]> (cherry picked from commit cf5000a) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Florian Westphal <[email protected]> commit 0873882 nft_rbtree_gc_elem() walks back and removes the end interval element that comes before the expired element. There is a small chance that we've cached this element as 'rbe_ge'. If this happens, we hold and test a pointer that has been queued for freeing. It also causes spurious insertion failures: $ cat test-testcases-sets-0044interval_overlap_0.1/testout.log Error: Could not process rule: File exists add element t s { 0 - 2 } ^^^^^^ Failed to insert 0 - 2 given: table ip t { set s { type inet_service flags interval,timeout timeout 2s gc-interval 2s } } The set (rbtree) is empty. The 'failure' doesn't happen on next attempt. Reason is that when we try to insert, the tree may hold an expired element that collides with the range we're adding. While we do evict/erase this element, we can trip over this check: if (rbe_ge && nft_rbtree_interval_end(rbe_ge) && nft_rbtree_interval_end(new)) return -ENOTEMPTY; rbe_ge was erased by the synchronous gc, we should not have done this check. Next attempt won't find it, so retry results in successful insertion. Restart in-kernel to avoid such spurious errors. Such restart are rare, unless userspace intentionally adds very large numbers of elements with very short timeouts while setting a huge gc interval. Even in this case, this cannot loop forever, on each retry an existing element has been removed. As the caller is holding the transaction mutex, its impossible for a second entity to add more expiring elements to the tree. After this it also becomes feasible to remove the async gc worker and perform all garbage collection from the commit path. Fixes: c9e6978 ("netfilter: nft_set_rbtree: Switch to node list walk for overlap detection") Signed-off-by: Florian Westphal <[email protected]> (cherry picked from commit 0873882) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Florian Westphal <[email protected]> commit d2fd2e4 upstream-diff There is no upstream commit to diff with. Picked directly from RH's branch. See message below for details. JIRA: https://issues.redhat.com/browse/RHEL-1720 JIRA: https://issues.redhat.com/browse/RHEL-1721 Upstream Status: RHEL only RHEL only. Proposed upstream but was rejected. I don't think we can force a rebase of nftables userland in RHEL <= 9.4. Even if we can do this, we would still need this change for z-stream. This change SHOULD NOT be forwarded into versions later than RHEL 9.4. For those releases nftables userspace should be updated to release 1.0.7 or later instead. nftables versions prior to commit 3975430b12d9 ("src: expand table command before evaluation"), i.e. 1.0.6 and earlier, will handle the following snippet in the wrong order: table ip t { chain c { jump { counter; } } } 1. create the table, chain,c and an anon chain. 2. append a rule to chain c to jump to the anon chain. 3. append the rule(s) (here: "counter") to the anon chain. (step 3 should be before 2). With below commit, this is now rejected by the kernel. Reason is that the 'jump {' rule added to chain c adds an explicit binding (dependency), i.e. the kernel will automatically remove the anon chain when userspace later asks to delete the 'jump {' rule from chain c. This caused crashes in the kernel in case of a errors further down in the same transaction. The abort part has to unroll all pending changes, including the request to add the rule 'jump {'. As its already bound, all the rules added to it get deleted as well. Because we tolerated late-add-after-bind, the transaction log also contains the NEWRULE requests (here "counter"), so those were deleted again. Instead of rejecting newrule-to-bound-chain, allow it iff the anon chain is new in this transaction and we are appending. Mark the newrule transaction as already_bound so abort path skips them. Fixes: 0ebc106 ("netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID") Reported-by: Timo Sigurdsson <[email protected]> Closes: https://lore.kernel.org/netfilter-devel/[email protected]/ Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Florian Westphal <[email protected]> (cherry picked from commit d2fd2e4) Signed-off-by: Marcin Wcisło <[email protected]>
…lush jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Pablo Neira Ayuso <[email protected]> commit 26cec9d Use the element object that is already offered instead. Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 26cec9d) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Pablo Neira Ayuso <[email protected]> commit 6509a2e .flush is always successful since this results from iterating over the set elements to toggle mark the element as inactive in the next generation. Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 6509a2e) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Pablo Neira Ayuso <[email protected]> commit 9dad402 upstream-diff Context conflict with the cve fix 5d4bb57 (wrong application order). Add placeholder structure and place it at the beginning of each struct nft_*_elem for each existing set backend, instead of exposing elements as void type to the frontend which defeats compiler type checks. Use this pointer to this new type to replace void *. This patch updates the following set backend API to use this new struct nft_elem_priv placeholder structure: - update - deactivate - flush - get as well as the following helper functions: - nft_set_elem_ext() - nft_set_elem_init() - nft_set_elem_destroy() - nf_tables_set_elem_destroy() This patch adds nft_elem_priv_cast() to cast struct nft_elem_priv to native element representation from the corresponding set backend. BUILD_BUG_ON() makes sure this .priv placeholder is always at the top of the opaque set element representation. Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 9dad402) Signed-off-by: Marcin Wcisło <[email protected]>
subsystem-update netfilter: centos-stream-9 cfd9694 cve CVE-2023-6111 commit-author Pablo Neira Ayuso <[email protected]> commit 93995bf upstream-diff Used the cleanly applying 9.4 backport 54e39cc The expired catchall element is not deactivated and removed from GC sync path. This path holds mutex so just call nft_setelem_data_deactivate() and nft_setelem_catchall_remove() before queueing the GC work. Fixes: 4a9e12e ("netfilter: nft_set_pipapo: call nft_trans_gc_queue_sync() in catchall GC") Reported-by: lonial con <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 93995bf) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 subsystem-update netfilter: centos-stream-9 cfd9694 commit-author Pablo Neira Ayuso <[email protected]> commit 8837ba3 upstream-diff Used the cleanly applying 9.4 backport 45aad05 list_for_each_entry_safe() does not work for the async case which runs under RCU, therefore, split GC logic for catchall in two functions instead, one for each of the sync and async GC variants. The catchall sync GC variant never sees a _DEAD bit set on ever, thus, this handling is removed in such case, moreover, allocate GC sync batch via GFP_KERNEL. Fixes: 93995bf ("netfilter: nf_tables: remove catchall element in GC sync path") Reported-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 8837ba3) Signed-off-by: Marcin Wcisło <[email protected]>
…_entry() jira VULN-430 cve-bf CVE-2023-4244 commit-author Ilya Leoshkevich <[email protected]> commit 837723b bpf_nf testcase fails on s390x: bpf_skb_ct_lookup() cannot find the entry that was added by bpf_ct_insert_entry() within the same BPF function. The reason is that this entry is deleted by nf_ct_gc_expired(). The CT timeout starts ticking after the CT confirmation; therefore nf_conn.timeout is initially set to the timeout value, and __nf_conntrack_confirm() sets it to the deadline value. bpf_ct_insert_entry() sets IPS_CONFIRMED_BIT, but does not adjust the timeout, making its value meaningless and causing false positives. Fix the problem by making bpf_ct_insert_entry() adjust the timeout, like __nf_conntrack_confirm(). Fixes: 2cdaa3e ("netfilter: conntrack: restore IPS_CONFIRMED out of nf_conntrack_hash_check_insert()") Signed-off-by: Ilya Leoshkevich <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Cc: Florian Westphal <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> (cherry picked from commit 837723b) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-34700 cve CVE-2023-42756 commit-author Jozsef Kadlecsik <[email protected]> commit 7433b6d Kyle Zeng reported that there is a race between IPSET_CMD_ADD and IPSET_CMD_SWAP in netfilter/ip_set, which can lead to the invocation of `__ip_set_put` on a wrong `set`, triggering the `BUG_ON(set->ref == 0);` check in it. The race is caused by using the wrong reference counter, i.e. the ref counter instead of ref_netlink. Fixes: 24e2278 ("netfilter: ipset: Add schedule point in call_ad().") Reported-by: Kyle Zeng <[email protected]> Closes: https://lore.kernel.org/netfilter-devel/ZPZqetxOmH+w%2Fmyc@westworld/#r Tested-by: Kyle Zeng <[email protected]> Signed-off-by: Jozsef Kadlecsik <[email protected]> Signed-off-by: Florian Westphal <[email protected]> (cherry picked from commit 7433b6d) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-8184 cve CVE-2024-26581 commit-author Pablo Neira Ayuso <[email protected]> commit 60c0c23 rbtree lazy gc on insert might collect an end interval element that has been just added in this transactions, skip end interval elements that are not yet active. Fixes: f718863 ("netfilter: nft_set_rbtree: fix overlap expiration walk") Cc: [email protected] Reported-by: lonial con <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 60c0c23) Signed-off-by: Marcin Wcisło <[email protected]>
…ith timeout jira VULN-836 cve CVE-2024-26643 commit-author Pablo Neira Ayuso <[email protected]> commit 552705a While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path. Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfa ("netfilter: nf_tables: use timestamp to check for set element timeout"). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case. According to 08e4c8c ("netfilter: nf_tables: mark newset as dead on transaction abort"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too. Cc: [email protected] Fixes: 5f68718 ("netfilter: nf_tables: GC transaction API to avoid race with control plane") Reported-by: Mingi Cho <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 552705a) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-4906 cve-pre CVE-2024-26925 commit-author Pablo Neira Ayuso <[email protected]> commit a45e688 Unlike early commit path stage which triggers a call to abort, an explicit release of the batch is required on abort, otherwise mutex is released and commit_list remains in place. Add WARN_ON_ONCE to ensure commit_list is empty from the abort path before releasing the mutex. After this patch, commit_list is always assumed to be empty before grabbing the mutex, therefore 03c1f1e ("netfilter: Cleanup nft_net->module_list from nf_tables_exit_net()") only needs to release the pending modules for registration. Cc: [email protected] Fixes: c0391b6 ("netfilter: nf_tables: missing validation from the abort path") Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit a45e688) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-4906 cve CVE-2024-26925 commit-author Pablo Neira Ayuso <[email protected]> commit 0d459e2 The commit mutex should not be released during the critical section between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC worker could collect expired objects and get the released commit lock within the same GC sequence. nf_tables_module_autoload() temporarily releases the mutex to load module dependencies, then it goes back to replay the transaction again. Move it at the end of the abort phase after nft_gc_seq_end() is called. Cc: [email protected] Fixes: 7203443 ("netfilter: nf_tables: GC transaction race with abort path") Reported-by: Kuan-Ting Chen <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 0d459e2) Signed-off-by: Marcin Wcisło <[email protected]>
pvts-mat
force-pushed
the
ciqlts9_2-CVE-batch-10
branch
from
e4508ce to
1a8251f
Compare
|
Commits metadata update
No problem, thanks for looking into it despite being sick. This commit is tricky, the |
6 participants
[LTS 9.2]
Fixed:
CVE-2022-48641 VULN-34024
CVE-2022-49917 VULN-66461
CVE-2022-49918 VULN-66488
CVE-2023-3777 VULN-6585
CVE-2023-4015 VULN-6613
CVE-2023-4244 VULN-430
CVE-2023-5197 VULN-34732
CVE-2023-52620 VULN-645
CVE-2023-52923 VULN-158865
CVE-2023-52924 VULN-158864
CVE-2023-53549 VULN-157585
CVE-2023-53635 VULN-158282
CVE-2023-7192 VULN-6817
Introduced:
CVE-2024-27012
CVE-2024-27017
CVE-2024-42109
CVE-2024-0193 VULN-6825
Introduced & fixed:
CVE-2023-42756 VULN-34700
CVE-2023-52433 VULN-158866
CVE-2023-52581 VULN-598
CVE-2023-52925 VULN-158863
CVE-2023-53304 VULN-155012
CVE-2023-53566 VULN-157645
CVE-2023-6111
CVE-2024-26581 VULN-8184
CVE-2024-26643 VULN-836
CVE-2024-26925 VULN-4906
Background
This PR was driven by CVE-2023-4244. The official upstream fix is given in the merge commit a2dd023. The merged branch of 5 commits had to be ported in whole. Although they fixed the CVE-2023-4244 problem they introduced multiple more. Additionally, the LTS 9.2
netfiltercodebase was not suited for the backport.The CVE-2023-4244 bug was already addressed in LTS 9.4 as part of the CentOS 9 "netlink api rebase" merge request. It was decided to port it in whole as it already dealt with similar unsuitability of the fix to the
netfiltercodebase of CentOS 9 at that time, and with the subsequent fixes. From the CentOS MR:Some of the involved commits required prerequisites contained in other, similar branches, ported in whole as well. Coupled with a few "loose" bugfixes the solution grew to almost 100 commits, although without any custom adaptations (clean cherry-picks).
The ported commits validated the CVE-2024-26581 which was put on hold before due to the modified code missing from the
ciqlts9_2codebase. The fix for CVE-2024-26581 was therefore included in this PR as well. All other CVEs were solved as a byproduct of backporting the CentOS 9 branches and some of their loose bugfixes.Solution strategy
Backporting strategy
Strategy for backporting CVE fixes, their prerequisites, and their bug fixes:
ciqlts9_4branch. For all commits obtained that way thekernel-mainlineSHA was nevertheless used in thecommitproperty and theupstream-diffcomment was included with reference to theciqlts9_4SHA actually used for the backport. The picks from 9.4 were only used if the picks from mainline generated conflicts. One commit (d2fd2e4) didn't even have an upstream equivalent.ciqlts9_2in next PRs.There were some exceptions to these rules, each of them addressed briefly in the Comment column of the Commits table, which see.
Tagging policy
Because of the "full branches" rule many commits incorporated in the PR contain fixes to bugs which don't have any specific CVE assigned. While some of them might have been identified as bugfixes for commits which do have specific CVE assigned (easy), or as their prerequisites (difficult), it was decided to not dwelve into these details and simplify the tagging.
cveandjiraproperties.cve-pre CVE-2023-4244: if they appear before the commit netfilter: nf_tables: GC transaction API to avoid race with control plane (official CVE-2023-4244 fix), orcve CVE-2023-4244: for all the commits after, as long as they still belong to the branch1(see Branches), orcve-bf CVE-2023-4244: for all the commits after branch1if they fix any of the commits in branches1,2,3.Conflicts
With the help of LTS 9.4 backports the solution for LTS 9.2 was obtained without any meaningful conflicts. The only ones occured when backporting 9dad402 and 2413893 and it stemmed from the 5d4bb57 fix present in
ciqlts9_2, which disturbed the chronology of changes. The conflicts might have been avoided entirely if it was reverted before the commits in this PR and then re-applied after, but that would result in an odd history. The conflicts were solved manually instead, preserving the meaning of the changes.Solution details
Tables
The internal structure of the solution can best be described by the Commits table. It's augmented with the CVEs, Branches and Commit titles tables providing some details about the entities referenced in the
Commitstable.The
CommitsandCVEstables were aimed to be fully enclosing the PR, which means:Commitscontains all commits from the PR (but not only them),Commitscontains all "Fixes" commits of every commit in the PR,Commitscontains all "Fixed by" commits of every commit in the PR,CVEscontains all CVEs associated with every commit in the PR,Commitscontains all commits associated with each CVE from theCVEstable (which may fall outside of PR).In this way a full picture of all solved and introduced problems can be painted.
Fields
Some cell values have universal meaning in all tables:
-: The value was considered / checked and it either doesn't apply or the value is missing, or the associated list is empty, depending on column context.Commits
Columns:
kernel-mainlinebranchciqlts9_4branchciqlts9_2branchIdfrom the previous column.1,2, …,7: CentOS 9 merge branches. For more information see the Branches table. Branches1,2,3are shown in full (all their commits included), others - not necessarily.0: The commit is part of CentOS 9 history but isn't a part of any merged branch.-: The commit is not even present in9.4history, so talking about "CentOS 9" branch is meaningless.H: Special "branch" id to identify commits belonging tociqlts9_2history.-: Commit not part of the PR.Clean ch-p mainline: The commit was cherry-picked cleanly directly from thekernel-mainlinebranch.Clean ch-p 9.4: The commit was cherry-picked cleanly from theciqlts9_4backported version.Conflict mainline: The cherry pick of thekernel-mainlinecommit resulted in conflicts and likewise theciqlts9_4version. See Conflicts for details about these cases.(F): Fixing.(I): Introducing.(?): Not established whether the commit was fixing or introducing this CVE.The sequence preserves ordering of commits in this PR, and of commits in branches
1,2,3(from the most recent). Within theB:-andB:Hgroups the commits are ordered by the commit date of thekernel-mainlineversion (from the most recent).CVE-2023-4563 (F), CVE-2023-52924 (F), CVE-2023-52925 (I)CVE-2023-4563 (I), CVE-2023-52923 (I), CVE-2023-52924 (I), CVE-2023-6817 (?), CVE-2024-26924 (I), CVE-2024-57947 (I), CVE-2025-38162 (I)CVE-2023-4563 (I), CVE-2023-52923 (I), CVE-2023-52924 (I)CVE-2023-4563 (I), CVE-2023-52923 (I), CVE-2023-52924 (I)Commit titles
The following table provides the link between
Idcolumn in theCommitstable and the commit's title for identification purposes.CVEs
Columns:
Branches
Columns:
Bin the Commits tableCommitstable.kABI check: passed
Boot test: passed
boot-test.log
Testing
The testing angle was running the selftests from the
netfiltertest suite in different debugging conditions.The tests set
The
netfiltersubsystem has its dedicatednetfilterselftests suite. The table below summarizes allnetfilterselftests available inciqlts9_2and their evaluation status.Functional tests: passed
Reference
kselftests–ciqlts9_2–run1.log
kselftests–ciqlts9_2–run2.log
kselftests–ciqlts9_2–run3.log
Patch
kselftests–ciqlts9_2-CVE-batch-10–run1.log
kselftests–ciqlts9_2-CVE-batch-10–run2.log
kselftests–ciqlts9_2-CVE-batch-10–run3.log
kselftests–ciqlts9_2-CVE-batch-10–run4.log
kselftests–ciqlts9_2-CVE-batch-10–run5.log
kselftests–ciqlts9_2-CVE-batch-10–run6.log
Comparison
KFENCE tests: passed
All tests in Functional tests were run on kernel with default (enabled) settings for KFENCE:
In case of any KFENCE errors a message like
would occur in the dmesg logs. No such messages were found
KASAN tests: passed
The patched kernel was compiled with the following options changed:
The tests set from the Functional testing was run 50 times with KASAN debug messages switched on. No KASAN logs appeared in the kernel's console.
kasan-console.log
To ensure the KASAN was set up properly the KUnit tests for KASAN were run.
kasan-self-test.log
Kmemleak tests: passed
The patched kernel was compiled with the following options changed:
The tests set from the Functional testing was run 50 times. Kmemleak scan was triggered at the end and the logs were read
No memory leaks were found.
KCSAN tests: passed relative
The patched
ciqlts9_2-CVE-batch-10and reference kernelciqlts9_2were compiled with KCSAN enabled:The tests set from Functional testing was run a couple of times on the patched kernel with some KCSAN bugs reported:
kcsan-patch.log
Likewise, the same set of test was run on the reference kernel:
kcsan-reference.log
The data race errors reported can be summarized as follows, where
xmeans the error occured and-that it did not.No data race in the patched kernel was encountered which wasn't encountered in the reference kernel as well. Additionally, judging by the stack traces, none of the races detected seemed to be associated with the
netfiltersubsystem.