[LTS 9.2] netfilter: CVE-2022-{48641, 49917, 49918}, CVE-2023-{3777, 4015, 4244, 5197, 52620, 52923, 52924, 53549, 53635, 7192} #668
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
jira VULN-66488 cve CVE-2022-49918 commit-author Zhengchao Shao <[email protected]> commit 3d00c6a During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn or ip_vs_conn_sync fails to be created, the initialization is successful by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't be found during the remove. The following is the stack information: name 'ip_vs_conn_sync' WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460 Modules linked in: Workqueue: netns cleanup_net RIP: 0010:remove_proc_entry+0x389/0x460 Call Trace: <TASK> __ip_vs_cleanup_batch+0x7d/0x120 ops_exit_list+0x125/0x170 cleanup_net+0x4ea/0xb00 process_one_work+0x9bf/0x1710 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30 </TASK> Fixes: 61b1ab4 ("IPVS: netns, add basic init per netns.") Signed-off-by: Zhengchao Shao <[email protected]> Acked-by: Julian Anastasov <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 3d00c6a) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-66461 cve CVE-2022-49917 commit-author Zhengchao Shao <[email protected]> commit 5663ed6 During the initialization of ip_vs_app_net_init(), if file ip_vs_app fails to be created, the initialization is successful by default. Therefore, the ip_vs_app file doesn't be found during the remove in ip_vs_app_net_cleanup(). It will cause WRNING. The following is the stack information: name 'ip_vs_app' WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460 Modules linked in: Workqueue: netns cleanup_net RIP: 0010:remove_proc_entry+0x389/0x460 Call Trace: <TASK> ops_exit_list+0x125/0x170 cleanup_net+0x4ea/0xb00 process_one_work+0x9bf/0x1710 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30 </TASK> Fixes: 457c4cb ("[NET]: Make /proc/net per network namespace") Signed-off-by: Zhengchao Shao <[email protected]> Acked-by: Julian Anastasov <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 5663ed6) Signed-off-by: Marcin Wcisło <[email protected]>
…ries jira VULN-157585 cve CVE-2023-53549 commit-author Jozsef Kadlecsik <[email protected]> commit 5e29dc3 When adding/deleting large number of elements in one step in ipset, it can take a reasonable amount of time and can result in soft lockup errors. The patch 5f7b51b ("netfilter: ipset: Limit the maximal range of consecutive elements to add/delete") tried to fix it by limiting the max elements to process at all. However it was not enough, it is still possible that we get hung tasks. Lowering the limit is not reasonable, so the approach in this patch is as follows: rely on the method used at resizing sets and save the state when we reach a smaller internal batch limit, unlock/lock and proceed from the saved state. Thus we can avoid long continuous tasks and at the same time removed the limit to add/delete large number of elements in one step. The nfnl mutex is held during the whole operation which prevents one to issue other ipset commands in parallel. Fixes: 5f7b51b ("netfilter: ipset: Limit the maximal range of consecutive elements to add/delete") Reported-by: [email protected] Signed-off-by: Jozsef Kadlecsik <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 5e29dc3) Signed-off-by: Marcin Wcisło <[email protected]>
…sion jira VULN-430 cve-pre CVE-2023-4244 commit-author Florian Westphal <[email protected]> commit 2b272bb When using a xfrm interface in a bridged setup (the outgoing device is bridged), the incoming packets in the xfrm interface are only tracked in the outgoing direction. $ brctl show bridge name interfaces br_eth1 eth1 $ conntrack -L tcp 115 SYN_SENT src=192... dst=192... [UNREPLIED] ... If br_netfilter is enabled, the first (encrypted) packet is received onR eth1, conntrack hooks are called from br_netfilter emulation which allocates nf_bridge info for this skb. If the packet is for local machine, skb gets passed up the ip stack. The skb passes through ip prerouting a second time. br_netfilter ip_sabotage_in supresses the re-invocation of the hooks. After this, skb gets decrypted in xfrm layer and appears in network stack a second time (after decryption). Then, ip_sabotage_in is called again and suppresses netfilter hook invocation, even though the bridge layer never called them for the plaintext incarnation of the packet. Free the bridge info after the first suppression to avoid this. I was unable to figure out where the regression comes from, as far as i can see br_netfilter always had this problem; i did not expect that skb is looped again with different headers. Fixes: c4b0e77 ("netfilter: avoid using skb->nf_bridge directly") Reported-and-tested-by: Wolfgang Nothdurft <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 2b272bb) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Florian Westphal <[email protected]> commit 94623f5 Recent attempt to ensure PREROUTING hook is executed again when a decrypted ipsec packet received on a bridge passes through the network stack a second time broke the physdev match in INPUT hook. We can't discard the nf_bridge info strct from sabotage_in hook, as this is needed by the physdev match. Keep the struct around and handle this with another conditional instead. Fixes: 2b272bb ("netfilter: br_netfilter: disable sabotage_in hook after first suppression") Reported-and-tested-by: Farid BENAMROUCHE <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 94623f5) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Florian Westphal <[email protected]> commit e58a171 We are not allowed to return an error at this point. Looking at the code it looks like ret is always 0 at this point, but its not. t = find_table_lock(net, repl->name, &ret, &ebt_mutex); ... this can return a valid table, with ret != 0. This bug causes update of table->private with the new blob, but then frees the blob right away in the caller. Syzbot report: BUG: KASAN: vmalloc-out-of-bounds in __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 Read of size 4 at addr ffffc90005425000 by task kworker/u4:4/74 Workqueue: netns cleanup_net Call Trace: kasan_report+0xbf/0x1f0 mm/kasan/report.c:517 __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 ebt_unregister_table+0x35/0x40 net/bridge/netfilter/ebtables.c:1372 ops_exit_list+0xb0/0x170 net/core/net_namespace.c:169 cleanup_net+0x4ee/0xb10 net/core/net_namespace.c:613 ... ip(6)tables appears to be ok (ret should be 0 at this point) but make this more obvious. Fixes: c58dd2d ("netfilter: Can't fail and free after table replacement") Reported-by: [email protected] Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit e58a171) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-34024 cve CVE-2022-48641 commit-author Florian Westphal <[email protected]> commit 62ce44c The bug fix was incomplete, it "replaced" crash with a memory leak. The old code had an assignment to "ret" embedded into the conditional, restore this. Fixes: 7997eff ("netfilter: ebtables: reject blobs that don't provide all entry points") Reported-and-tested-by: [email protected] Signed-off-by: Florian Westphal <[email protected]> (cherry picked from commit 62ce44c) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Florian Westphal <[email protected]> commit 4a02426 The xtables packet traverser performs an unconditional local_bh_disable(), but the nf_tables evaluation loop does not. Functions that are called from either xtables or nftables must assume that they can be called in process context. inet_twsk_deschedule_put() assumes that no softirq interrupt can occur. If tproxy is used from nf_tables its possible that we'll deadlock trying to aquire a lock already held in process context. Add a small helper that takes care of this and use it. Link: https://lore.kernel.org/netfilter-devel/[email protected]/ Fixes: 4ed8eb6 ("netfilter: nf_tables: Add native tproxy support") Reported-and-tested-by: Major Dávid <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 4a02426) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Pablo Neira Ayuso <[email protected]> commit 33c7aba upstream-diff Actually picked the 9.4 backport c085531 which applies cleanly without context conflicts Elements with an end interval flag set on do not store extensions. The global set definition is currently setting on the timeout and stateful expression for end interval elements. This leads to skipping end interval elements from the set->ops->walk() path as the expired check bogusly reports true. Moreover, do not set up stateful expressions for elements with end interval flag set on since this is never used. Fixes: 6503842 ("netfilter: nf_tables: allow to specify stateful expression in set definition") Fixes: 8d8540c ("netfilter: nft_set_rbtree: add timeout support") Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 33c7aba) Signed-off-by: Marcin Wcisło <[email protected]>
…tion jira VULN-430 cve-pre CVE-2023-4244 commit-author Pablo Neira Ayuso <[email protected]> commit c9e6978 ...instead of a tree descent, which became overly complicated in an attempt to cover cases where expired or inactive elements would affect comparisons with the new element being inserted. Further, it turned out that it's probably impossible to cover all those cases, as inactive nodes might entirely hide subtrees consisting of a complete interval plus a node that makes the current insertion not overlap. To speed up the overlap check, descent the tree to find a greater element that is closer to the key value to insert. Then walk down the node list for overlap detection. Starting the overlap check from rb_first() unconditionally is slow, it takes 10 times longer due to the full linear traversal of the list. Moreover, perform garbage collection of expired elements when walking down the node list to avoid bogus overlap reports. For the insertion operation itself, this essentially reverts back to the implementation before commit 7c84d41 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion"), except that cases of complete overlap are already handled in the overlap detection phase itself, which slightly simplifies the loop to find the insertion point. Based on initial patch from Stefano Brivio, including text from the original patch description too. Fixes: 7c84d41 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion") Reviewed-by: Stefano Brivio <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit c9e6978) Signed-off-by: Marcin Wcisło <[email protected]>
…collection jira VULN-430 cve-pre CVE-2023-4244 commit-author Pablo Neira Ayuso <[email protected]> commit 5d235d6 Skip interference with an ongoing transaction, do not perform garbage collection on inactive elements. Reset annotated previous end interval if the expired element is marked as busy (control plane removed the element right before expiration). Fixes: 8d8540c ("netfilter: nft_set_rbtree: add timeout support") Reviewed-by: Stefano Brivio <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 5d235d6) Signed-off-by: Marcin Wcisło <[email protected]>
…wner jira VULN-430 cve-pre CVE-2023-4244 commit-author Pablo Neira Ayuso <[email protected]> commit 92f3e96 NFT_MSG_GETSETELEM returns -EPERM when fetching set elements that belong to table that has an owner. This results in empty set/map listing from userspace. Fixes: 6001a93 ("netfilter: nftables: introduce table ownership") Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 92f3e96) Signed-off-by: Marcin Wcisło <[email protected]>
…conntrack() jira VULN-6817 cve CVE-2023-7192 commit-author Hangyu Hua <[email protected]> commit ac48939 nf_ct_put() needs to be called to put the refcount got by nf_conntrack_find_get() to avoid refcount leak when nf_conntrack_hash_check_insert() fails. Fixes: 7d367e0 ("netfilter: ctnetlink: fix soft lockup when netlink adds new entries (v2)") Signed-off-by: Hangyu Hua <[email protected]> Acked-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit ac48939) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Florian Westphal <[email protected]> commit e6d57e9 nf_conntrack_hash_check_insert() callers free the ct entry directly, via nf_conntrack_free. This isn't safe anymore because nf_conntrack_hash_check_insert() might place the entry into the conntrack table and then delteted the entry again because it found that a conntrack extension has been removed at the same time. In this case, the just-added entry is removed again and an error is returned to the caller. Problem is that another cpu might have picked up this entry and incremented its reference count. This results in a use-after-free/double-free, once by the other cpu and once by the caller of nf_conntrack_hash_check_insert(). Fix this by making nf_conntrack_hash_check_insert() not fail anymore after the insertion, just like before the 'Fixes' commit. This is safe because a racing nf_ct_iterate() has to wait for us to release the conntrack hash spinlocks. While at it, make the function return -EAGAIN in the rmmod (genid changed) case, this makes nfnetlink replay the command (suggested by Pablo Neira). Fixes: c56716c ("netfilter: extensions: introduce extension genid count") Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit e6d57e9) Signed-off-by: Marcin Wcisło <[email protected]>
…check_insert() jira VULN-430 cve-pre CVE-2023-4244 commit-author Pablo Neira Ayuso <[email protected]> commit 2cdaa3e e6d57e9 ("netfilter: conntrack: fix rmmod double-free race") consolidates IPS_CONFIRMED bit set in nf_conntrack_hash_check_insert(). However, this breaks ctnetlink: # conntrack -I -p tcp --timeout 123 --src 1.2.3.4 --dst 5.6.7.8 --state ESTABLISHED --sport 1 --dport 4 -u SEEN_REPLY conntrack v1.4.6 (conntrack-tools): Operation failed: Device or resource busy This is a partial revert of the aforementioned commit to restore IPS_CONFIRMED. Fixes: e6d57e9 ("netfilter: conntrack: fix rmmod double-free race") Reported-by: Stéphane Graber <[email protected]> Tested-by: Stéphane Graber <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 2cdaa3e) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Eric Dumazet <[email protected]> commit c77737b Customers using GKE 1.25 and 1.26 are facing conntrack issues root caused to commit c9c3b68 ("netfilter: conntrack: make max chain length random"). Even if we assume Uniform Hashing, a bucket often reachs 8 chained items while the load factor of the hash table is smaller than 0.5 With a limit of 16, we reach load factors of 3. With a limit of 32, we reach load factors of 11. With a limit of 40, we reach load factors of 15. With a limit of 50, we reach load factors of 24. This patch changes MIN_CHAINLEN to 50, to minimize risks. Ideally, we could in the future add a cushion based on expected load factor (2 * nf_conntrack_max / nf_conntrack_buckets), because some setups might expect unusual values. Fixes: c9c3b68 ("netfilter: conntrack: make max chain length random") Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit c77737b) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Jeremy Sowden <[email protected]> commit 068d82e The values in the protocol registers are two bytes wide. However, when parsing the register loads, the code currently uses the larger 16-byte size of a `union nf_inet_addr`. Change it to use the (correct) size of a `union nf_conntrack_man_proto` instead. Fixes: d07db98 ("netfilter: nf_tables: introduce nft_validate_register_load()") Signed-off-by: Jeremy Sowden <[email protected]> Reviewed-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 068d82e) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Jeremy Sowden <[email protected]> commit ec2c591 The values in the protocol registers are two bytes wide. However, when parsing the register loads, the code currently uses the larger 16-byte size of a `union nf_inet_addr`. Change it to use the (correct) size of a `union nf_conntrack_man_proto` instead. Fixes: 8a6bf5d ("netfilter: nft_masq: support port range") Signed-off-by: Jeremy Sowden <[email protected]> Reviewed-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit ec2c591) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Jeremy Sowden <[email protected]> commit 1f617b6 The values in the protocol registers are two bytes wide. However, when parsing the register loads, the code currently uses the larger 16-byte size of a `union nf_inet_addr`. Change it to use the (correct) size of a `union nf_conntrack_man_proto` instead. Fixes: d07db98 ("netfilter: nf_tables: introduce nft_validate_register_load()") Signed-off-by: Jeremy Sowden <[email protected]> Reviewed-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 1f617b6) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Jeremy Sowden <[email protected]> commit 4939245 `nft_redir_inet_type.maxattrs` was being set, presumably because of a cut-and-paste error, to `NFTA_MASQ_MAX`, instead of `NFTA_REDIR_MAX`. Fixes: 63ce394 ("netfilter: nft_redir: add inet support") Signed-off-by: Jeremy Sowden <[email protected]> Reviewed-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 4939245) Signed-off-by: Marcin Wcisło <[email protected]>
…h-all elements jira VULN-430 cve-pre CVE-2023-4244 commit-author Pablo Neira Ayuso <[email protected]> commit d4eb7e3 If NFT_SET_ELEM_CATCHALL is set on, then userspace provides no set element key. Otherwise, bail out with -EINVAL. Fixes: aaa3104 ("netfilter: nftables: add catch-all set element support") Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit d4eb7e3) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-158282 cve CVE-2023-53635 commit-author Tzung-Bi Shih <[email protected]> commit 73db1b8 (struct nf_conn)->timeout is an interval before the conntrack confirmed. After confirmed, it becomes a timestamp. It is observed that timeout of an unconfirmed conntrack: - Set by calling ctnetlink_change_timeout(). As a result, `nfct_time_stamp` was wrongly added to `ct->timeout` twice. - Get by calling ctnetlink_dump_timeout(). As a result, `nfct_time_stamp` was wrongly subtracted. Call Trace: <TASK> dump_stack_lvl ctnetlink_dump_timeout __ctnetlink_glue_build ctnetlink_glue_build __nfqnl_enqueue_packet nf_queue nf_hook_slow ip_mc_output ? __pfx_ip_finish_output ip_send_skb ? __pfx_dst_output udp_send_skb udp_sendmsg ? __pfx_ip_generic_getfrag sock_sendmsg Separate the 2 cases in: - Setting `ct->timeout` in __nf_ct_set_timeout(). - Getting `ct->timeout` in ctnetlink_dump_timeout(). Pablo appends: Update ctnetlink to set up the timeout _after_ the IPS_CONFIRMED flag is set on, otherwise conntrack creation via ctnetlink breaks. Note that the problem described in this patch occurs since the introduction of the nfnetlink_queue conntrack support, select a sufficiently old Fixes: tag for -stable kernel to pick up this fix. Fixes: a4b4766 ("netfilter: nfnetlink_queue: rename related to nfqueue attaching conntrack info") Signed-off-by: Tzung-Bi Shih <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 73db1b8) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Florian Westphal <[email protected]> commit 9a32e98 The ->cleanup callback needs to be removed, this doesn't work anymore as the transaction mutex is already released in the ->abort function. Just do it after a successful validation pass, this either happens from commit or abort phases where transaction mutex is held. Fixes: f102d66 ("netfilter: nf_tables: use dedicated mutex to guard transactions") Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 9a32e98) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Florian Westphal <[email protected]> commit e3c361b nft_trans_FOO objects all share a common nft_trans base structure, but trailing fields depend on the real object size. Access is only safe after trans->msg_type check. Check for rule type first. Found by code inspection. Fixes: 1a94e38 ("netfilter: nf_tables: add NFTA_RULE_ID attribute") Signed-off-by: Florian Westphal <[email protected]> (cherry picked from commit e3c361b) Signed-off-by: Marcin Wcisło <[email protected]>
…lper jira VULN-430 cve-pre CVE-2023-4244 commit-author Tijs Van Buggenhout <[email protected]> commit e1f543d An nf_conntrack_helper from nf_conn_help may become NULL after DNAT. Observed when TCP port 1720 (Q931_PORT), associated with h323 conntrack helper, is DNAT'ed to another destination port (e.g. 1730), while nfqueue is being used for final acceptance (e.g. snort). This happenned after transition from kernel 4.14 to 5.10.161. Workarounds: * keep the same port (1720) in DNAT * disable nfqueue * disable/unload h323 NAT helper $ linux-5.10/scripts/decode_stacktrace.sh vmlinux < /tmp/kernel.log BUG: kernel NULL pointer dereference, address: 0000000000000084 [..] RIP: 0010:nf_conntrack_update (net/netfilter/nf_conntrack_core.c:2080 net/netfilter/nf_conntrack_core.c:2134) nf_conntrack [..] nfqnl_reinject (net/netfilter/nfnetlink_queue.c:237) nfnetlink_queue nfqnl_recv_verdict (net/netfilter/nfnetlink_queue.c:1230) nfnetlink_queue nfnetlink_rcv_msg (net/netfilter/nfnetlink.c:241) nfnetlink [..] Fixes: ee04805 ("netfilter: conntrack: make conntrack userspace helpers work again") Signed-off-by: Tijs Van Buggenhout <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit e1f543d) Signed-off-by: Marcin Wcisło <[email protected]>
…ft_dump_basechain_hook() jira VULN-430 cve-pre CVE-2023-4244 commit-author Gavrilov Ilia <[email protected]> commit bd05876 upstream-diff Used the cleanly applying 9.4 backport 04580de The nla_nest_start_noflag() function may fail and return NULL; the return value needs to be checked. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d54725c ("netfilter: nf_tables: support for multiple devices per netdev hook") Signed-off-by: Gavrilov Ilia <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit bd05876) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Pablo Neira Ayuso <[email protected]> commit a1a64a1 If caller reports ENOMEM, then stop iterating over the batch and send a single netlink message to userspace to report OOM. Fixes: cbb8125 ("netfilter: nfnetlink: deliver netlink errors on batch completion") Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit a1a64a1) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Florian Westphal <[email protected]> commit dc1c9fd This reverts "netfilter: nf_tables: skip netdev events generated on netns removal". The problem is that when a veth device is released, the veth release callback will also queue the peer netns device for removal. Its possible that the peer netns is also slated for removal. In this case, the device memory is already released before the pre_exit hook of the peer netns runs: BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0 Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45 Workqueue: netns cleanup_net Call Trace: nf_hook_entry_head+0x1b8/0x1d0 __nf_unregister_net_hook+0x76/0x510 nft_netdev_unregister_hooks+0xa0/0x220 __nft_release_hook+0x184/0x490 nf_tables_pre_exit_net+0x12f/0x1b0 .. Order is: 1. First netns is released, veth_dellink() queues peer netns device for removal 2. peer netns is queued for removal 3. peer netns device is released, unreg event is triggered 4. unreg event is ignored because netns is going down 5. pre_exit hook calls nft_netdev_unregister_hooks but device memory might be free'd already. Fixes: 68a3765 ("netfilter: nf_tables: skip netdev events generated on netns removal") Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit dc1c9fd) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-157645 cve CVE-2023-53566 commit-author Florian Westphal <[email protected]> commit 61ae320 There is no guarantee that rb_prev() will not return NULL in nft_rbtree_gc_elem(): general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [ctrliq#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] nft_add_set_elem+0x14b0/0x2990 nf_tables_newsetelem+0x528/0xb30 Furthermore, there is a possible use-after-free while iterating, 'node' can be free'd so we need to cache the next value to use. 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 61ae320) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve-pre CVE-2023-4244 commit-author Kuniyuki Iwashima <[email protected]> commit 24e2278 syzkaller found a repro that causes Hung Task [0] with ipset. The repro first creates an ipset and then tries to delete a large number of IPs from the ipset concurrently: IPSET_ATTR_IPADDR_IPV4 : 172.20.20.187 IPSET_ATTR_CIDR : 2 The first deleting thread hogs a CPU with nfnl_lock(NFNL_SUBSYS_IPSET) held, and other threads wait for it to be released. Previously, the same issue existed in set->variant->uadt() that could run so long under ip_set_lock(set). Commit 5e29dc3 ("netfilter: ipset: Rework long task execution when adding/deleting entries") tried to fix it, but the issue still exists in the caller with another mutex. While adding/deleting many IPs, we should release the CPU periodically to prevent someone from abusing ipset to hang the system. Note we need to increment the ipset's refcnt to prevent the ipset from being destroyed while rescheduling. [0]: INFO: task syz-executor174:268 blocked for more than 143 seconds. Not tainted 6.4.0-rc1-00145-gba79e9a73284 ctrliq#1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor174 state:D stack:0 pid:268 ppid:260 flags:0x0000000d Call trace: __switch_to+0x308/0x714 arch/arm64/kernel/process.c:556 context_switch kernel/sched/core.c:5343 [inline] __schedule+0xd84/0x1648 kernel/sched/core.c:6669 schedule+0xf0/0x214 kernel/sched/core.c:6745 schedule_preempt_disabled+0x58/0xf0 kernel/sched/core.c:6804 __mutex_lock_common kernel/locking/mutex.c:679 [inline] __mutex_lock+0x6fc/0xdb0 kernel/locking/mutex.c:747 __mutex_lock_slowpath+0x14/0x20 kernel/locking/mutex.c:1035 mutex_lock+0x98/0xf0 kernel/locking/mutex.c:286 nfnl_lock net/netfilter/nfnetlink.c:98 [inline] nfnetlink_rcv_msg+0x480/0x70c net/netfilter/nfnetlink.c:295 netlink_rcv_skb+0x1c0/0x350 net/netlink/af_netlink.c:2546 nfnetlink_rcv+0x18c/0x199c net/netfilter/nfnetlink.c:658 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0x664/0x8cc net/netlink/af_netlink.c:1365 netlink_sendmsg+0x6d0/0xa4c net/netlink/af_netlink.c:1913 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0x4b8/0x810 net/socket.c:2503 ___sys_sendmsg net/socket.c:2557 [inline] __sys_sendmsg+0x1f8/0x2a4 net/socket.c:2586 __do_sys_sendmsg net/socket.c:2595 [inline] __se_sys_sendmsg net/socket.c:2593 [inline] __arm64_sys_sendmsg+0x80/0x94 net/socket.c:2593 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x84/0x270 arch/arm64/kernel/syscall.c:52 el0_svc_common+0x134/0x24c arch/arm64/kernel/syscall.c:142 do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193 el0_svc+0x2c/0x7c arch/arm64/kernel/entry-common.c:637 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591 Reported-by: syzkaller <[email protected]> Fixes: a7b4f98 ("netfilter: ipset: IP set core support") Signed-off-by: Kuniyuki Iwashima <[email protected]> Acked-by: Jozsef Kadlecsik <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> (cherry picked from commit 24e2278) Signed-off-by: Marcin Wcisło <[email protected]>
jira VULN-430 cve CVE-2023-4244 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 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 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 cve CVE-2023-4244 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 cve CVE-2023-4244 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 cve CVE-2023-4244 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 cve CVE-2023-4244 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 cve CVE-2023-4244 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 cve CVE-2023-4244 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 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 cve CVE-2023-4244 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 cve CVE-2023-4244 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 cve CVE-2023-4244 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 cve CVE-2023-4244 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 cve CVE-2023-4244 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]>
cve CVE-2023-6111 commit-author Pablo Neira Ayuso <[email protected]> commit 93995bf 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 cve CVE-2023-4244 commit-author Pablo Neira Ayuso <[email protected]> commit 8837ba3 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]>
Collaborator
|
@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 |
Collaborator
|
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. |
Collaborator
Contributor
Author
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: |
Contributor
Author
|
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. |
…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
2919917 to
520390b
Compare
Contributor
Author
|
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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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 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
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-0193 VULN-6825
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. 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