[LTS 9.2] netfilter: CVE-2022-{48641, 49917, 49918}, CVE-2023-{3777, 4015, 4244, 5197, 52620, 52923, 52924, 53549, 53635, 7192}

[pvts-mat]

[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 netfilter codebase 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 netfilter codebase of CentOS 9 at that time, and with the subsequent fixes. From the CentOS MR:

This is a major rebase to get the set element garbage collection into RHEL. This rework was necessary to address race conditions between the netlink control plane, the datapath (set element insertion/removal via nft_dynset expression from the nftables ruleset) and the asynchronous garbage collection to remove timed-out elements.

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_2 codebase. 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:

• Following the solution in LTS 9.4: The backport of CVE fixes in this PR relied heavily on the solutions existing in LTS 9.4. Multiple commits were cherry-picked directly from the ciqlts9_4 branch. For all commits obtained that way the kernel-mainline SHA was nevertheless used in the commit property and the upstream-diff comment was included with reference to the ciqlts9_4 SHA 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.
• Backporting full branches: Instead of backporting singular commits as CVE fixes or prerequisites the whole branches merged into CentOS 9 containing them were backported, to eliminate the risk of breaking nontrivial, branch-internal dependencies. The list of all branches used or considered can be found in Branches.
• Minimizing the size of the PR: The full solution for CVE-2023-4244 introduced a bunch of issues which require fixing as well. Some of them have CVEs assigned, some not. Backporting them all, coupled with the "full branches" rule would increase the size of the PR considerably. As a result the PR may be failing the "check for fixes" test. Nevertheless all the fixes required are identified and listed, with a plan to be incorporated into ciqlts9_2 in 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.

1. Every commit officially identified as a fix for some CVE is described accordingly with the cve and jira properties.
2. All other commits are identified as:
   • 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), or
   • cve CVE-2023-4244: for all the commits after, as long as they still belong to the branch 1 (see Branches), or
   • cve-bf CVE-2023-4244: for all the commits after branch 1 if they fix any of the commits in branches 1, 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 Commits table.

The Commits and CVEs tables were aimed to be fully enclosing the PR, which means:

• Commits contains all commits from the PR (but not only them),
• Commits contains all "Fixes" commits of every commit in the PR,
• Commits contains all "Fixed by" commits of every commit in the PR,
• CVEs contains all CVEs associated with every commit in the PR,
• Commits contains all commits associated with each CVE from the CVEs table (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.
• (empty cell): The value was not explored (because there was no need to).

Commits

Columns:

• Id: Short numerical identifier of the commit

• mainline: Commit hash in the kernel-mainline branch

• 9.4: Commit hash in the ciqlts9_4 branch

• 9.2: Commit hash in the ciqlts9_2 branch

• Fixes: All commits listed under the "Fixes" tag, specified by Id from the previous column.

• B: The branch identifier

  • 1, 2, …, 7: CentOS 9 merge branches. For more information see the Branches table. Branches 1, 2, 3 are 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 in 9.4 history, so talking about "CentOS 9" branch is meaningless.
  • H: Special "branch" id to identify commits belonging to ciqlts9_2 history.

• PR / PR1: Whether the commit was included in the PR / PR1, and how, also under which commit.

  • PR: The solution originally proposed in the PR
  • PR1: The reduced solution, as propposed in comment [LTS 9.2] netfilter: CVE-2022-{48641, 49917, 49918}, CVE-2023-{3777, 4015, 4244, 5197, 52620, 52923, 52924, 53549, 53635, 7192} #668 (comment)

  Values:

  • -: Commit not part of the PR.
  • Clean ch-p mainline: The commit was cherry-picked cleanly directly from the kernel-mainline branch.
  • Clean ch-p 9.4: The commit was cherry-picked cleanly from the ciqlts9_4 backported version.
  • Conflict mainline: The cherry pick of the kernel-mainline commit resulted in conflicts and likewise the ciqlts9_4 version. See Conflicts for details about these cases.
  • Contextual conflict ch-p 9.4: The cherry pick of the ciqlts9_4 commit resulted in conflicts, but only contextual (with interdiff remaining the same after resolution).

• ΔPR: Whether the commit in PR1 differs from original PR (either code commited or message or the existence of commit itself)

  • !: There is a change
  • 0: No change
  • -: Doesn't apply

• Comment: Justification of why the commit was / wasn't included in the PR.

• CVE: List of associated commits

  • (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 the B:- and B:H groups the commits are ordered by the commit date of the kernel-mainline version (from the most recent).

Id	mainline	9.4	9.2	Fixes	B	PR	PR1	ΔPR	CVE
1	ea77c39	-	-	4	-	-	-	-	CVE-2025-38120 (F)
2	4c5c6aa	-	-	140	-	-	-	-	CVE-2025-38162 (F)
3	7ffc748	-	-	56	-	-	-	-	CVE-2024-54031 (I)
4	791a615	-	-	140	-	-	-	-	CVE-2024-57947 (F), CVE-2025-38120 (I)
5	9f6958b	-	-	46	-	-	-	-	CVE-2024-42109 (F)
6	e79b47a	-	-	72	-	-	-	-	CVE-2024-27012 (F)
7	3cfc9ec	-	-	140	-	-	-	-	CVE-2024-26924 (F)
8	29b359c	-	-	74	-	-	-	-	CVE-2024-27017 (F)
9	ab0beaf	-	-	28	-	-	-	-	-
10	6b1ca88	-	-	59	-	-	-	-	-
11	08e4c8c	121604f	-	59	4	-	-	-	-
12	ffb40fb	5df20fe	-	56	4	-	-	-	-
13	7315dc1	d51e691	-	59	4	-	-	-	CVE-2024-0193 (F)
14	a7d5a95	3f8af15	-	80	4	-	-	-	-
15	4c90bba	abe4ffe	-	78	4	-	-	-	-
16	ebd032f	-	-	76	-	-	-	-	-
17	ea078ae	8d34a7a	-	82	5	-	-	-	-
18	7e9be11	4052bb3	-	78	5	-	-	-	-
19	f18e712	-	-	100, 156	-	-	-	-	-
20	0d459e2	-	-	45	-	1a8251f Clean ch-p mainline	b1df305 Clean ch-p mainline	0	CVE-2024-26925 (F)
21	a45e688	-	-	132	-	85f8112 Clean ch-p mainline	96c6b6f Clean ch-p mainline	0	-
22	552705a	4e5f985	-	59	0	2a61411 Clean ch-p mainline	018fea0 Clean ch-p mainline	0	CVE-2024-26643 (F)
23	60c0c23	6cb02fd	-	58	0	4c7c53d Clean ch-p mainline	aa67aa7 Clean ch-p mainline	0	CVE-2024-26581 (F)
24	7433b6d	5579e1e	-	84	7	65bec04 Clean ch-p mainline	2390fc0 Clean ch-p mainline	0	CVE-2023-42756 (F)
25	837723b	8a3ba5c	-	101	6	cad2875 Clean ch-p mainline	2637124 Clean ch-p mainline	0	-
26	8837ba3	45aad05	-	27	1	7ed6da7 Clean ch-p 9.4	5165cc4 Clean ch-p 9.4	0	-
27	93995bf	54e39cc	-	39	1	4f574b5 Clean ch-p 9.4	fd5ce20 Clean ch-p 9.4	0	CVE-2023-6111 (F)
28	9dad402	71f4dce	-	-	1	eb93588 Conflict mainline	667c97b Conflict mainline	0	-
29	6509a2e	b04945d	-	-	1	6d81448 Clean ch-p mainline	7028892 Clean ch-p mainline	0	-
30	26cec9d	8d1189c	-	-	1	dd9b146 Clean ch-p mainline	b4219bc Clean ch-p mainline	0	-
31	-	d2fd2e4	-	24	1	fd335f7 Clean ch-p 9.4	f63aa2e Clean ch-p 9.4	0	-
32	0873882	c46c169	-	106	1	cd99125 Clean ch-p mainline	d48698b Clean ch-p mainline	0	-
33	cf5000a	0cb54fa	-	59	1	ffca1b8 Clean ch-p mainline	e9f5d5a Clean ch-p mainline	0	CVE-2023-52581 (F)
34	c9bd265	30de344	-	129	1	f83a4fb Clean ch-p mainline	f76d039 Clean ch-p mainline	0	-
35	23a3bfd	59ae9e4	-	162	1	01f8bc5 Clean ch-p mainline	b36dd02 Clean ch-p mainline	0	-
36	b079155	465bbb2	-	56	1	5fc6241 Clean ch-p mainline	bde76df Clean ch-p mainline	0	-
37	6d365ea	a28769d	-	59	1	289c533 Clean ch-p mainline	bc51b92 Clean ch-p mainline	0	-
38	96b3330	d1e4596	-	56	1	b02b275 Clean ch-p mainline	28e99df Clean ch-p mainline	0	-
39	4a9e12e	bee501c	-	59, 56	1	385eb17 Clean ch-p mainline	15678b9 Clean ch-p mainline	0	CVE-2023-6111 (I)
40	f15f29f	29530d2	-	134	1	088386e Clean ch-p 9.4	d5e58bd Clean ch-p 9.4	0	CVE-2023-5197 (F)
41	2ee52ae	e33bf66	-	56	1	64cef3c Clean ch-p mainline	5a0da61 Clean ch-p mainline	0	CVE-2023-52433 (F)
42	8e51830	ef5cec9	-	56	1	8215032 Clean ch-p mainline	0d2043f Clean ch-p mainline	0	-
43	5e1be4c	69cb8d9	-	140	1	b5ef541 Clean ch-p mainline	68d8c53 Clean ch-p mainline	0	-
44	8357bc9	f678a58	-	59	1	2af8206 Clean ch-p mainline	c84e122 Clean ch-p mainline	0	-
45	7203443	4afe09a	-	59	1	003f16a Clean ch-p mainline	5ac72e7 Clean ch-p mainline	0	CVE-2024-26925 (I)
46	2c9f029	318076c	-	121	1	c3501fe Clean ch-p mainline	ba88352 Clean ch-p mainline	0	CVE-2024-42109 (I)
47	23185c6	925e3d3	-	151	1	819d340 Clean ch-p mainline	e222bd9 Clean ch-p mainline	0	-
48	02c6c24	727722d	-	59	1	4e1bdb5 Clean ch-p mainline	2ad516a Clean ch-p mainline	0	-
49	6a33d8b	58e5f04	-	59	1	d9411ea Clean ch-p mainline	5e61402 Clean ch-p mainline	0	CVE-2023-4244 (F)
50	7845914	5911169	-	60	1	dc4d96b Clean ch-p mainline	818e323 Clean ch-p mainline	0	CVE-2023-52925 (F)
51	90e5b34	94d514d	-	130	1	dc3f47f Clean ch-p mainline	7f8f505 Clean ch-p mainline	0	CVE-2023-4569 (F)
52	08713cb	bd94f35	-	59, 56	1	2caabe7 Clean ch-p mainline	6b1e827 Clean ch-p mainline	0	-
53	b9f052d	ad6241e	-	76	1	10d8670 Clean ch-p mainline	d6f8377 Clean ch-p mainline	0	-
54	a2dd023	37e26ec	-	-	1	35fc7f8 Clean ch-p mainline	e85c9b9 Clean ch-p mainline	0	-
55	c92db30	65afc3d	-	60	1	c735dca Clean ch-p mainline	24f55fe Clean ch-p mainline	0	-
56	f6c383b	bb3c6b5	-	158, 147, 140	1	979027b Clean ch-p mainline	363d4d6 Clean ch-p mainline	0	CVE-2023-52923 (F), CVE-2023-52433 (I)
57	0a771f7	7e1fc03	-	119	1	5c467c1 Clean ch-p mainline	d5302ea Clean ch-p mainline	0	CVE-2023-4015 (F)
58	f718863	5c00ebd	-	106	1	e6e9f4a Clean ch-p mainline	4c36195 Clean ch-p mainline	0	CVE-2023-53304 (F), CVE-2024-26581 (I)
59	5f68718	bf6d3e9	-	159	1	f20b3d1 Clean ch-p 9.4	672fb4d Contextual conflict ch-p 9.4	!	CVE-2023-4244 (F), CVE-2023-52581 (I), CVE-2024-0193 (I), CVE-2024-26643 (I)
60	2413893	49f8fb9	-	158, 147, 140	1	6ac7cf9 Conflict mainline	2f57885 Conflict mainline	0	CVE-2023-4563 (F), CVE-2023-52924 (F), CVE-2023-52925 (I)
61	6eaf41e	f5739eb	ae5e128	134	1	-	-	0	CVE-2023-3777 (F)
62	751d460	8ca0cc6	-	134	1	fb61b84 Clean ch-p mainline	962da46 Clean ch-p mainline	0	-
63	ddbd8be	4427002	-	152	1	76c619a Clean ch-p mainline	cb5e2cd Clean ch-p mainline	0	-
64	1689f25	854ec83	-	162	1	791a1c4 Clean ch-p 9.4	3b0e7bc Contextual conflict ch-p 9.4	!	-
65	b389139	12f4f55	-	71, 72	1	7e0d217 Clean ch-p mainline	9665aa8 Clean ch-p mainline	0	-
66	e26d300	0a49baa	-	-	1	0e4257e Clean ch-p mainline	70805b3 Clean ch-p mainline	0	CVE-2023-52620 (F)
67	b770283	ec166b7	-	120	1	8543902 Clean ch-p mainline	135a883 Clean ch-p mainline	0	-
68	62e1e94	51f6ae5	-	134	1	865abbb Clean ch-p mainline	5e4b3e0 Clean ch-p mainline	0	-
69	938154b	5a63039	-	162	1	60546ef Clean ch-p mainline	031fad6 Clean ch-p mainline	0	-
70	c88c535	46d60b5	-	162	1	b364fc7 Clean ch-p mainline	231900d Clean ch-p mainline	0	-
71	d6b4786	3965620	-	-	1	53d8922 Clean ch-p mainline	268e019 Clean ch-p mainline	0	-
72	628bd3e	e564400	-	149	1	94e7f14 Clean ch-p mainline	1a84dee Clean ch-p mainline	0	CVE-2024-27012 (I)
73	34aae2c	f74ccdb	-	-	1	4b2118c Clean ch-p 9.4	0f7dccc Clean ch-p 9.4	0	-
74	2b84e21	5d9bf13	-	140	1	35539f8 Clean ch-p mainline	97eb9a9 Clean ch-p mainline	0	CVE-2024-27017 (I)
75	a4878ee	3d294f8	-	-	1	fc529c9 Clean ch-p mainline	3e6c036 Clean ch-p mainline	0	-
76	212ed75	9e21c09	-	140	1	a6ec042 Clean ch-p mainline	38a2eae Clean ch-p mainline	0	-
77	341b694	2313c52	-	-	1	5b15619 Clean ch-p 9.4	84bd3d9 Clean ch-p 9.4	0	-
78	079cd63	7c45d32	-	-	2	3a0433a Clean ch-p mainline	-	!	-
79	1fb7696	6f6e9c9	-	80	2	4d3403c Clean ch-p mainline	-	!	-
80	f80a612	f6dad62	-	-	2	9373d94 Clean ch-p mainline	-	!	-
81	b53c116	fbc09cf	-	-	2	831e94f Clean ch-p mainline	-	!	-
82	8daa8fd	ce1ee31	-	-	2	9e60027 Clean ch-p 9.4	-	!	-
83	7d34aa3	55895d0	-	-	2	0a9dbb6 Clean ch-p 9.4	-	!	-
84	24e2278	ce29c51	-	164	3	a4bd02a Clean ch-p mainline	a4bd02a Clean ch-p mainline	0	CVE-2023-42756 (I)
85	61ae320	6bdf948	-	106	3	d8c7f23 Clean ch-p mainline	d8c7f23 Clean ch-p mainline	0	CVE-2023-53566 (F)
86	dc1c9fd	7ef0f95	-	126	3	29c892c Clean ch-p mainline	29c892c Clean ch-p mainline	0	-
87	a1a64a1	9fd6dee	-	160	3	2a8d0f8 Clean ch-p mainline	2a8d0f8 Clean ch-p mainline	0	-
88	bd05876	04580de	-	141	3	aae18ee Clean ch-p 9.4	aae18ee Clean ch-p 9.4	0	-
89	e1f543d	cf89456	-	136	3	953d9e5 Clean ch-p mainline	953d9e5 Clean ch-p mainline	0	-
90	e3c361b	a1fc1a6	-	150	3	17c94a0 Clean ch-p mainline	17c94a0 Clean ch-p mainline	0	-
91	9a32e98	c4fdaba	-	146	3	e3430b4 Clean ch-p mainline	e3430b4 Clean ch-p mainline	0	-
92	73db1b8	05445b5	-	155	3	c1a1eda Clean ch-p mainline	c1a1eda Clean ch-p mainline	0	CVE-2023-53635 (F)
93	d4eb7e3	d17406d	-	130	3	47bd453 Clean ch-p mainline	47bd453 Clean ch-p mainline	0	-
94	d46fc89	39bf804	492891d	130	3	-	-	0	-
95	4939245	2b6d20b	-	143	3	123af97 Clean ch-p mainline	123af97 Clean ch-p mainline	0	-
96	1f617b6	fa487d6	-	157	3	e1e661b Clean ch-p mainline	e1e661b Clean ch-p mainline	0	-
97	ec2c591	ccbff46	-	154	3	447d85c Clean ch-p mainline	447d85c Clean ch-p mainline	0	-
98	068d82e	f920dc0	-	157	3	1b857d4 Clean ch-p mainline	1b857d4 Clean ch-p mainline	0	-
99	c77737b	eef5069	-	127	3	83124b4 Clean ch-p mainline	83124b4 Clean ch-p mainline	0	-
100	fdf6491	9f8f92b	-	123	3	-	-	0	-
101	2cdaa3e	a9985ec	-	102	3	dc0d099 Clean ch-p mainline	dc0d099 Clean ch-p mainline	0	-
102	e6d57e9	5c92dbf	-	124	3	0b95e9b Clean ch-p mainline	0b95e9b Clean ch-p mainline	0	-
103	ac48939	e9d8ea1	-	163	3	20d501f Clean ch-p mainline	20d501f Clean ch-p mainline	0	CVE-2023-7192 (F)
104	92f3e96	f60201c	-	131	3	0091981 Clean ch-p mainline	0091981 Clean ch-p mainline	0	-
105	5d235d6	aebf798	-	147	3	357195e Clean ch-p mainline	357195e Clean ch-p mainline	0	-
106	c9e6978	97220e3	-	138	3	9ccfa1c Clean ch-p mainline	9ccfa1c Clean ch-p mainline	0	CVE-2023-53304 (I), CVE-2023-53566 (I)
107	33c7aba	c085531	-	139, 147	3	fb225ea Clean ch-p 9.4	fb225ea Clean ch-p 9.4	0	-
108	4a02426	344967d	-	145	3	c7d8326 Clean ch-p mainline	c7d8326 Clean ch-p mainline	0	-
109	62ce44c	a3248b4	-	122	3	9216afa Clean ch-p mainline	9216afa Clean ch-p mainline	0	CVE-2022-48641 (F)
110	e58a171	eaddfeb	-	161	3	bd72688 Clean ch-p mainline	bd72688 Clean ch-p mainline	0	-
111	94623f5	637c557	-	112	3	fa24e83 Clean ch-p mainline	fa24e83 Clean ch-p mainline	0	-
112	2b272bb	52691f7	-	144	3	32f0f88 Clean ch-p mainline	32f0f88 Clean ch-p mainline	0	-
113	5e29dc3	be67665	-	128	3	b98c9e1 Clean ch-p mainline	b98c9e1 Clean ch-p mainline	0	CVE-2023-53549 (F)
114	5663ed6	d05f7f6	-	166	3	6abf37f Clean ch-p mainline	6abf37f Clean ch-p mainline	0	CVE-2022-49917 (F)
115	3d00c6a	b332e00	-	165	3	57f5c51 Clean ch-p mainline	57f5c51 Clean ch-p mainline	0	CVE-2022-49918 (F)
116	317eb96	f16e21d	5d4bb57	140	H	-	-	-	CVE-2023-6817 (?)
117	e7c8899	e287383	3578ca7	134	H	-	-	-
118	87b5a5c	fb82489	eabcf73	140	H	-	-	-	CVE-2023-4004 (F)
119	4bedf9e	3aa75fd	0ce53ab		H	-	-	-	CVE-2023-3610 (I), CVE-2023-4015 (I)
120	123b996	e358654	e358654		H	-	-	-	-
121	d4bc827	8313c48	8313c48		H	-	-	-	CVE-2022-49920 (?)
122	7997eff	a36f9c2	a36f9c2		H	-	-	-	CVE-2022-48641 (I)
123	90d1daa	44ad5e5	44ad5e5		H	-	-	-	-
124	c56716c	a48c260	a48c260		H	-	-	-	CVE-2022-48974 (?)
125	babc3dc	e68e7ee	e68e7ee	138, 148	H	-	-	-	-
126	68a3765	4c1f351	4c1f351		H	-	-	-	CVE-2021-47452 (?)
127	c9c3b68	cb1c10e	cb1c10e		H	-	-	-	-
128	5f7b51b	5f7b51b	5f7b51b		H	-	-	-	CVE-2023-53549 (I)
129	179d9ba	179d9ba	179d9ba		H	-	-	-	CVE-2024-26835 (?), CVE-2024-27065 (?), CVE-2024-35897 (?), CVE-2024-35900 (?)
130	aaa3104	aaa3104	aaa3104		H	-	-	-	CVE-2021-47106 (?), CVE-2023-4569 (I), CVE-2024-1085 (?)
131	6001a93	6001a93	6001a93		H	-	-	-	CVE-2021-47394 (?), CVE-2022-49920 (?)
132	c0391b6	c0391b6	c0391b6		H	-	-	-	-
133	226a88d	226a88d	226a88d	138	H	-	-	-	-
134	d0e2c7d	d0e2c7d	d0e2c7d		H	-	-	-	CVE-2022-39190 (?), CVE-2023-3610 (I), CVE-2023-3777 (I), CVE-2023-4147 (?), CVE-2023-5197 (I)
135	33d0779	33d0779	33d0779	147, 138	H	-	-	-	-
136	ee04805	ee04805	ee04805		H	-	-	-	-
137	72239f2	72239f2	72239f2	138	H	-	-	-	-
138	7c84d41	7c84d41	7c84d41	-	H	-	-	-	-
139	6503842	6503842	6503842		H	-	-	-	CVE-2021-46283 (?)
140	3c4287f	3c4287f	3c4287f	-	H	-	-	-	CVE-2023-4004 (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)
141	d54725c	d54725c	d54725c		H	-	-	-	CVE-2022-48691 (?), CVE-2024-36005 (?)
142	d0a8d87	d0a8d87	d0a8d87	-	H	-	-	-	-
143	63ce394	63ce394	63ce394		H	-	-	-	-
144	c4b0e77	c4b0e77	c4b0e77		H	-	-	-	-
145	4ed8eb6	4ed8eb6	4ed8eb6		H	-	-	-	CVE-2022-50001 (?)
146	f102d66	f102d66	f102d66		H	-	-	-	-
147	8d8540c	8d8540c	8d8540c	-	H	-	-	-	CVE-2023-4563 (I), CVE-2023-52923 (I), CVE-2023-52924 (I)
148	d2df92e	d2df92e	d2df92e	153	H	-	-	-	-
149	5910544	5910544	5910544		H	-	-	-	CVE-2024-27011 (?)
150	1a94e38	1a94e38	1a94e38		H	-	-	-	-
151	8aeff92	8aeff92	8aeff92		H	-	-	-	-
152	c016c7e	c016c7e	c016c7e		H	-	-	-	-
153	e701001	e701001	e701001	-	H	-	-	-	-
154	8a6bf5d	8a6bf5d	8a6bf5d		H	-	-	-	-
155	a4b4766	a4b4766	a4b4766		H	-	-	-	CVE-2023-53635 (I)
156	0ebc106	e7c8899	e7c8899	-	H	-	-	-
157	d07db98	d07db98	d07db98		H	-	-	-	-
158	9d09829	9d09829	9d09829	-	H	-	-	-	CVE-2023-4563 (I), CVE-2023-52923 (I), CVE-2023-52924 (I)
159	cfed7e1	cfed7e1	cfed7e1	-	H	-	-	-	CVE-2023-4244 (I)
160	cbb8125	cbb8125	cbb8125		H	-	-	-	-
161	c58dd2d	c58dd2d	c58dd2d		H	-	-	-	-
162	9651851	9651851	9651851		H	-	-	-	CVE-2022-1016 (?), CVE-2022-49293 (?), CVE-2023-35001 (?), CVE-2024-42070 (?)
163	7d367e0	7d367e0	7d367e0		H	-	-	-	CVE-2023-7192 (I)
164	a7b4f98	a7b4f98	a7b4f98		H	-	-	-	CVE-2024-56637 (?)
165	61b1ab4	61b1ab4	61b1ab4		H	-	-	-	CVE-2022-49918 (I), CVE-2025-40018 (?)
166	457c4cb	457c4cb	457c4cb		H	-	-	-	CVE-2022-49917 (I)

Commit titles

The following table provides the link between Id column in the Commits table and the commit's title for identification purposes.

Id	Title
1	`netfilter: nf_set_pipapo_avx2: fix initial map fill`
2	`netfilter: nft_set_pipapo: prevent overflow in lookup table allocation`
3	`netfilter: nft_set_hash: skip duplicated elements pending gc run`
4	`netfilter: nf_set_pipapo: fix initial map fill`
5	`netfilter: nf_tables: unconditionally flush pending work before notifier`
6	`netfilter: nf_tables: restore set elements when delete set fails`
7	`netfilter: nft_set_pipapo: do not free live element`
8	`netfilter: nft_set_pipapo: walk over current view on netlink dump`
9	`netfilter: nft_set_pipapo: remove static in nft_pipapo_get()`
10	`netfilter: nf_tables: skip dead set elements in netlink dump`
11	`netfilter: nf_tables: mark newset as dead on transaction abort`
12	`netfilter: nft_set_pipapo: prefer gfp_kernel allocation`
13	`netfilter: nf_tables: skip set commit for deleted/destroyed sets`
14	`netfilter: nf_tables: bogus ENOENT when destroying element which does not exist`
15	`netfilter: nf_tables: do not refresh timeout when resetting element`
16	`netfilter: nf_tables: do not remove elements if set backend implements .abort`
17	`netfilter: nf_tables: Audit log rule reset`
18	`netfilter: nf_tables: Audit log setelem reset`
19	`linux/netfilter.h: fix kernel-doc warnings`
20	`netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path`
21	`netfilter: nf_tables: release batch on table validation from abort path`
22	`netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout`
23	`netfilter: nft_set_rbtree: skip end interval element from gc`
24	`netfilter: ipset: Fix race between IPSET_CMD_CREATE and IPSET_CMD_SWAP`
25	`netfilter, bpf: Adjust timeouts of non-confirmed CTs in bpf_ct_insert_entry()`
26	`netfilter: nf_tables: split async and sync catchall in two functions`
27	`netfilter: nf_tables: remove catchall element in GC sync path`
28	`netfilter: nf_tables: expose opaque set element as struct nft_elem_priv`
29	`netfilter: nf_tables: set backend .flush always succeeds`
30	`netfilter: nft_set_pipapo: no need to call pipapo_deactivate() from flush`
31	`netfilter: nf_tables: work around newrule after chain binding`
32	`netfilter: nf_tables: nft_set_rbtree: fix spurious insertion failure`
33	`netfilter: nf_tables: fix memleak when more than 255 elements expired`
34	`netfilter: nf_tables: disable toggling dormant table state more than once`
35	`netfilter: nf_tables: disallow element removal on anonymous sets`
36	`netfilter: nft_set_hash: try later when GC hits EAGAIN on iteration`
37	`netfilter: nft_set_pipapo: stop GC iteration if GC transaction allocation fails`
38	`netfilter: nft_set_rbtree: use read spinlock to avoid datapath contention`
39	`netfilter: nft_set_pipapo: call nft_trans_gc_queue_sync() in catchall GC`
40	`netfilter: nf_tables: disallow rule removal from chain binding`
41	`netfilter: nft_set_rbtree: skip sync GC for new elements in this transaction`
42	`netfilter: nf_tables: defer gc run if previous batch is still pending`
43	`netfilter: nf_tables: fix out of memory error handling`
44	`netfilter: nf_tables: use correct lock to protect gc_list`
45	`netfilter: nf_tables: GC transaction race with abort path`
46	`netfilter: nf_tables: flush pending destroy work before netlink notifier`
47	`netfilter: nft_dynset: disallow object maps`
48	`netfilter: nf_tables: GC transaction race with netns dismantle`
49	`netfilter: nf_tables: fix GC transaction races with netns and netlink event exit path`
50	`netfilter: nf_tables: don't fail inserts if duplicate has expired`
51	`netfilter: nf_tables: deactivate catchall elements in next generation`
52	`netfilter: nf_tables: fix kdoc warnings after gc rework`
53	`netfilter: nf_tables: fix false-positive lockdep splat`
54	`netfilter: nf_tables: remove busy mark and gc batch API`
55	`netfilter: nft_set_hash: mark set element as dead when deleting from packet path`
56	`netfilter: nf_tables: adapt set backend to use GC transaction API`
57	`netfilter: nf_tables: skip immediate deactivate in _PREPARE_ERROR`
58	`netfilter: nft_set_rbtree: fix overlap expiration walk`
59	`netfilter: nf_tables: GC transaction API to avoid race with control plane`
60	`netfilter: nf_tables: don't skip expired elements during walk`
61	`netfilter: nf_tables: skip bound chain on rule flush`
62	`netfilter: nf_tables: skip bound chain in netns release path`
63	`netfilter: nf_tables: fix spurious set element insertion failure`
64	`netfilter: nf_tables: report use refcount overflow`
65	`netfilter: nf_tables: fix underflow in chain reference counter`
66	`netfilter: nf_tables: disallow timeout for anonymous sets`
67	`netfilter: nf_tables: disallow updates of anonymous sets`
68	`netfilter: nf_tables: reject unbound chain set before commit phase`
69	`netfilter: nf_tables: reject unbound anonymous set before commit phase`
70	`netfilter: nf_tables: disallow element updates of bound anonymous sets`
71	`netfilter: nf_tables: fix underflow in object reference counter`
72	`netfilter: nf_tables: drop map element references from preparation phase`
73	`netfilter: nf_tables: validate variable length element extension`
74	`netfilter: nft_set_pipapo: .walk does not deal with generations`
75	`netfilter: nf_tables: relax set/map validation checks`
76	`netfilter: nf_tables: integrate pipapo into commit protocol`
77	`netfilter: nf_tables: upfront validation of data via nft_data_init()`
78	`netfilter: nf_tables: Introduce NFT_MSG_GETSETELEM_RESET`
79	`netfilter: nf_tables: fix wrong pointer passed to PTR_ERR()`
80	`netfilter: nf_tables: add support to destroy operation`
81	`netfilter: nf_tables: set element extended ACK reporting support`
82	`netfilter: nf_tables: Introduce NFT_MSG_GETRULE_RESET`
83	`netfilter: nf_tables: Extend nft_expr_ops::dump callback parameters`
84	`netfilter: ipset: Add schedule point in call_ad().`
85	`netfilter: nft_set_rbtree: fix null deref on element insertion`
86	`netfilter: nf_tables: always release netdev hooks from notifier`
87	`netfilter: nfnetlink: skip error delivery on batch in case of ENOMEM`
88	`netfilter: nf_tables: Add null check for nla_nest_start_noflag() in nft_dump_basechain_hook()`
89	`netfilter: conntrack: fix NULL pointer dereference in nf_confirm_cthelper`
90	`netfilter: nf_tables: fix nft_trans type confusion`
91	`netfilter: nf_tables: don't write table validation state without mutex`
92	`netfilter: conntrack: fix wrong ct->timeout value`
93	`netfilter: nf_tables: tighten netlink attribute requirements for catch-all elements`
94	`netfilter: nf_tables: validate catch-all set elements`
95	`` netfilter: nft_redir: correct value of inet type `.maxattrs` ``
96	`netfilter: nft_redir: correct length for loading protocol registers`
97	`netfilter: nft_masq: correct length for loading protocol registers`
98	`netfilter: nft_nat: correct length for loading protocol registers`
99	`netfilter: conntrack: adopt safer max chain length`
100	`netfilter: ctnetlink: make event listener tracking global`
101	`netfilter: conntrack: restore IPS_CONFIRMED out of nf_conntrack_hash_check_insert()`
102	`netfilter: conntrack: fix rmmod double-free race`
103	`netfilter: ctnetlink: fix possible refcount leak in ctnetlink_create_conntrack()`
104	`netfilter: nf_tables: allow to fetch set elements when table has an owner`
105	`netfilter: nft_set_rbtree: skip elements in transaction from garbage collection`
106	`netfilter: nft_set_rbtree: Switch to node list walk for overlap detection`
107	`netfilter: nf_tables: do not set up extensions for end interval`
108	`netfilter: tproxy: fix deadlock due to missing BH disable`
109	`netfilter: ebtables: fix memory leak when blob is malformed`
110	`netfilter: ebtables: fix table blob use-after-free`
111	`netfilter: br_netfilter: fix recent physdev match breakage`
112	`netfilter: br_netfilter: disable sabotage_in hook after first suppression`
113	`netfilter: ipset: Rework long task execution when adding/deleting entries`
114	`ipvs: fix WARNING in ip_vs_app_net_cleanup()`
115	`ipvs: fix WARNING in __ip_vs_cleanup_batch()`
116	`netfilter: nft_set_pipapo: skip inactive elements during set walk`
117	`netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID`
118	`netfilter: nft_set_pipapo: fix improper element removal`
119	`netfilter: nf_tables: fix chain binding transaction logic`
120	`netfilter: nf_tables: honor set timeout and garbage collection updates`
121	`netfilter: nf_tables: netlink notifier might race to release objects`
122	`netfilter: ebtables: reject blobs that don't provide all entry points`
123	`netfilter: conntrack: add nf_conntrack_events autodetect mode`
124	`netfilter: extensions: introduce extension genid count`
125	`netfilter: nft_set_rbtree: overlap detection with element re-addition after deletion`
126	`netfilter: nf_tables: skip netdev events generated on netns removal`
127	`netfilter: conntrack: make max chain length random`
128	`netfilter: ipset: Limit the maximal range of consecutive elements to add/delete`
129	`netfilter: nf_tables: fix table flag updates`
130	`netfilter: nftables: add catch-all set element support`
131	`netfilter: nftables: introduce table ownership`
132	`netfilter: nf_tables: missing validation from the abort path`
133	`netfilter: nft_set_rbtree: Handle outcomes of tree rotations in overlap detection`
134	`netfilter: nf_tables: add NFT_CHAIN_BINDING`
135	`netfilter: nft_set_rbtree: Don't account for expired elements on insertion`
136	`netfilter: conntrack: make conntrack userspace helpers work again`
137	`netfilter: nft_set_rbtree: Drop spurious condition for overlap detection on insertion`
138	`netfilter: nft_set_rbtree: Detect partial overlaps on insertion`
139	`netfilter: nf_tables: allow to specify stateful expression in set definition`
140	`nf_tables: Add set type for arbitrary concatenation of ranges`
141	`netfilter: nf_tables: support for multiple devices per netdev hook`
142	`netfilter: nft_dynset: support for element deletion`
143	`netfilter: nft_redir: add inet support`
144	`netfilter: avoid using skb->nf_bridge directly`
145	`netfilter: nf_tables: Add native tproxy support`
146	`netfilter: nf_tables: use dedicated mutex to guard transactions`
147	`netfilter: nft_set_rbtree: add timeout support`
148	`netfilter: nft_set_rbtree: handle element re-addition after deletion`
149	`netfilter: nf_tables: revisit chain/object refcounting from elements`
150	`netfilter: nf_tables: add NFTA_RULE_ID attribute`
151	`netfilter: nf_tables: add stateful object reference to set elements`
152	`netfilter: nf_tables: honor NLM_F_EXCL flag in set element insertion`
153	`netfilter: nft_rbtree: allow adjacent intervals with dynamic updates`
154	`netfilter: nft_masq: support port range`
155	`netfilter: nfnetlink_queue: rename related to nfqueue attaching conntrack info`
156	`netfilter: move tee_active to core`
157	`netfilter: nf_tables: introduce nft_validate_register_load()`
158	`netfilter: nft_hash: add support for timeouts`
159	`netfilter: nf_tables: add set garbage collection helpers`
160	`netfilter: nfnetlink: deliver netlink errors on batch completion`
161	`netfilter: Can't fail and free after table replacement`
162	`netfilter: add nftables`
163	`netfilter: ctnetlink: fix soft lockup when netlink adds new entries (v2)`
164	`netfilter: ipset: IP set core support`
165	`IPVS: netns, add basic init per netns.`
166	`[NET]: Make /proc/net per network namespace`

CVEs

Columns:

• CVE, VULN, CVSS: Self explanatory
• Status: Relation of CVE and the patch contained in this PR.
  • F: Fixed by the patch
  • I: Introduced by the patch
  • -: None of the above

CVE	VULN	CVSS	Status
CVE-2021-46283			-
CVE-2021-47106			-
CVE-2021-47394			-
CVE-2021-47452			-
CVE-2022-1016			-
CVE-2022-39190			-
CVE-2022-48641	VULN-34024	4.4	F
CVE-2022-48691			-
CVE-2022-48974			-
CVE-2022-49293			-
CVE-2022-49917	VULN-66461	1.9	F
CVE-2022-49918	VULN-66488	4.4	F
CVE-2022-49920			-
CVE-2022-50001			-
CVE-2023-35001			-
CVE-2023-3610			-
CVE-2023-3777	VULN-6585	7.8	F
CVE-2023-4004		7.8	-
CVE-2023-4015	VULN-6613	7.8	F
CVE-2023-4147			-
CVE-2023-4244	VULN-430	7	F
CVE-2023-42756	VULN-34700	4.4	I, F
CVE-2023-4563	?	rejected	F
CVE-2023-4569	-	5.5	F
CVE-2023-5197	VULN-34732	6.6	F
CVE-2023-52433	VULN-158866	-	I, F
CVE-2023-52581	VULN-598	7	I, F
CVE-2023-52620	VULN-645	2.5	F
CVE-2023-52923	VULN-158865	5.5	F
CVE-2023-52924	VULN-158864	5.5	F
CVE-2023-52925	VULN-158863	5.5	I, F
CVE-2023-53304	VULN-155012	5.5	I, F
CVE-2023-53549	VULN-157585	5.5	F
CVE-2023-53566	VULN-157645	6.4	I, F
CVE-2023-53635	VULN-158282	5.5	F
CVE-2023-6111	-	7.8	I, F
CVE-2023-6817		7.8	-
CVE-2023-7192	VULN-6817	5.5	F
CVE-2024-0193	VULN-6825	7.8	I
CVE-2024-1085			-
CVE-2024-26581	VULN-8184	6.4	I, F
CVE-2024-26643	VULN-836	4.7	I, F
CVE-2024-26835			-
CVE-2024-26924		5.5	-
CVE-2024-26925	VULN-4906	7	I, F
CVE-2024-27011			-
CVE-2024-27012	?	5.5	I
CVE-2024-27017	?	5.5	I
CVE-2024-27065			-
CVE-2024-35897			-
CVE-2024-35900			-
CVE-2024-36005			-
CVE-2024-42109	?	5.5	I
CVE-2024-54031			-
CVE-2024-56637			-
CVE-2024-57947		7.1	-
CVE-2025-38120		5.5	-
CVE-2025-38162		7	-
CVE-2025-40018			-

Branches

Columns:

• B: Same as B in the Commits table
• Length: Size of the branch, in commits, from fork to merge.
• Full: Whether the branch is presented fully in the Commits table.
• Merge commit, Merge name, Comment: Self explanatory

B	Merge commit	Merge name	Length	Full	Comment
1	cfd9694	`netfilter: nf_tables: netlink api rebase on net.git`	53	yes
2	c05955e	`netfilter: nf_tables: Support resetting state in rules and set elements`	7	yes
3	e4726e3	`9.3 backports from upstream`	33	yes
4	f875124	`netfilter: nf_tables: backports from upstream`	16	no
5	3e3b830	`audit: backport kernel audit enhancements and fixes up to upstream v6.6`	16	no
6	0ca27d7	`bpf: update to 6.4`	434	no	Not specifically a netfilter merge
7	a40a6f6	`netfilter: ipset: Fix race between IPSET_CMD_CREATE and IPSET_CMD_SWAP`	1	yes

kABI check: passed

DEBUG=1 CVE=CVE-batch-10 ./ninja.sh _kabi_check_kernel__x86_64--test--ciqlts9_2-CVE-batch-10

[0/1] kabi_check_kernel	Check ABI of kernel [ciqlts9_2-CVE-batch-10]	_kabi_check_kernel__x86_64--test--ciqlts9_2-CVE-batch-10
++ uname -m
+ python3 /data/src/ctrliq-github-haskell/kernel-dist-git-el-9.2/SOURCES/check-kabi -k /data/src/ctrliq-github-haskell/kernel-dist-git-el-9.2/SOURCES/Module.kabi_x86_64 -s vms/x86_64--build--ciqlts9_2/build_files/kernel-src-tree-ciqlts9_2-CVE-batch-10/Module.symvers
kABI check passed
+ touch state/kernels/ciqlts9_2-CVE-batch-10/x86_64/kabi_checked

Boot test: passed

boot-test.log

Testing

The testing angle was running the selftests from the netfilter test suite in different debugging conditions.

The tests set

The netfilter subsystem has its dedicated netfilter selftests suite. The table below summarizes all netfilter selftests available in ciqlts9_2 and their evaluation status.

	Test	Status	Inclusion	Dependencies
1	`netfilter:nft_trans_stress.sh`	not finishing	Omitted
2	`netfilter:bridge_brouter.sh`	skip	Omitted
3	`netfilter:conntrack_icmp_related.sh`	pass	Included
4	`netfilter:conntrack_tcp_unreplied.sh`	pass	Included
5	`netfilter:conntrack_vrf.sh`	pass	Included	iperf3, conntrack
6	`netfilter:ipip-conntrack-mtu.sh`	pass	Included	iptables, socat
7	`netfilter:ipvs.sh`	pass	Included	ipvsadm
8	`netfilter:nf_nat_edemux.sh`	pass	Included	iperf3, iptables
9	`netfilter:nft_concat_range.sh`	fail	Omitted
10	`netfilter:nft_conntrack_helper.sh`	pass	Included	conntrack
11	`netfilter:nft_fib.sh`	pass	Included
12	`netfilter:nft_flowtable.sh`	fail	Omitted
13	`netfilter:nft_meta.sh`	pass	Included
14	`netfilter:nft_nat.sh`	pass	Included	socat, conntrack, nft
15	`netfilter:nft_queue.sh`	pass	Included	nft
16	`netfilter:rpath.sh`	pass	Included	iptables, nft

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

$ ktests.xsh diff  kselftests*.log

Column    File
--------  --------------------------------------------
Status0   kselftests--ciqlts9_2--run1.log
Status1   kselftests--ciqlts9_2--run2.log
Status2   kselftests--ciqlts9_2--run3.log
Status3   kselftests--ciqlts9_2-CVE-batch-10--run1.log
Status4   kselftests--ciqlts9_2-CVE-batch-10--run2.log
Status5   kselftests--ciqlts9_2-CVE-batch-10--run3.log
Status6   kselftests--ciqlts9_2-CVE-batch-10--run4.log
Status7   kselftests--ciqlts9_2-CVE-batch-10--run5.log
Status8   kselftests--ciqlts9_2-CVE-batch-10--run6.log

TestCase                              Status0  Status1  Status2  Status3  Status4  Status5  Status6  Status7  Status8  Summary
netfilter:conntrack_icmp_related.sh   pass     pass     pass     pass     pass     pass     pass     pass     pass     same
netfilter:conntrack_tcp_unreplied.sh  pass     pass     pass     pass     pass     pass     pass     pass     pass     same
netfilter:conntrack_vrf.sh            pass     pass     pass     pass     pass     pass     pass     pass     pass     same
netfilter:ipip-conntrack-mtu.sh       pass     pass     pass     pass     pass     pass     pass     pass     pass     same
netfilter:ipvs.sh                     pass     pass     pass     pass     pass     pass     pass     pass     pass     same
netfilter:nf_nat_edemux.sh            pass     pass     pass     pass     pass     pass     pass     pass     pass     same
netfilter:nft_conntrack_helper.sh     pass     pass     pass     pass     pass     pass     pass     pass     pass     same
netfilter:nft_fib.sh                  pass     pass     pass     pass     pass     pass     pass     pass     pass     same
netfilter:nft_meta.sh                 pass     pass     pass     pass     pass     pass     pass     pass     pass     same
netfilter:nft_nat.sh                  pass     pass     pass     pass     pass     pass     pass     pass     pass     same
netfilter:nft_queue.sh                pass     pass     pass     pass     pass     pass     pass     pass     pass     same
netfilter:rpath.sh                    pass     pass     pass     pass     pass     pass     pass     pass     pass     same

KFENCE tests: passed

All tests in Functional tests were run on kernel with default (enabled) settings for KFENCE:

# CONFIG_KFENCE_DEFERRABLE is not set
# CONFIG_KFENCE_KUNIT_TEST is not set
CONFIG_KFENCE_NUM_OBJECTS=255
CONFIG_KFENCE_SAMPLE_INTERVAL=100
# CONFIG_KFENCE_STATIC_KEYS is not set
CONFIG_KFENCE=y

In case of any KFENCE errors a message like

[  462.929989] ==================================================================
[  462.931009] BUG: KFENCE: out-of-bounds write in trie_get_next_key+0x203/0x2f0
[  462.931009]
…

would occur in the dmesg logs. No such messages were found

$ sudo grep --ignore-case kfence /var/log/libvirt/qemu/x86_64--test--ciqlts9_2-CVE-batch-10.log

[    0.162931] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.159006] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.162034] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.163187] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.163219] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.161861] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.161250] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.161250] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.162728] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)

KASAN tests: passed

The patched kernel was compiled with the following options changed:

`CONFIG_KASAN`	y
`CONFIG_KASAN_MODULE_TEST`	m
`CONFIG_STACKTRACE`	y
`CONFIG_RANDOMIZE_MEMORY`	n

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.

# modprobe test_kasan
…
# modprobe test_kasan_module
…

kasan-self-test.log

Kmemleak tests: passed

The patched kernel was compiled with the following options changed:

`CONFIG_DEBUG_KMEMLEAK`	y
`CONFIG_DEBUG_KMEMLEAK_TEST`	y

The tests set from the Functional testing was run 50 times. Kmemleak scan was triggered at the end and the logs were read

# echo scan > /sys/kernel/debug/kmemleak
# cat /sys/kernel/debug/kmemleak

No memory leaks were found.

KCSAN tests: passed relative

The patched ciqlts9_2-CVE-batch-10 and reference kernel ciqlts9_2 were compiled with KCSAN enabled:

`CONFIG_KCSAN`

y

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 x means the error occured and - that it did not.

Data race	Ref	Patch
`_find_next_bit+0x47/0x120`	x	x
`audit_log_start.part.0 / skb_dequeue`	x	x
`cgroup_rstat_flush_locked / cgroup_rstat_updated`	x	-
`d_add / d_add`	x	x
`ep_poll / ep_poll_callback`	x	-
`folio_mark_accessed / workingset_activation`	x	-
`kauditd_thread / skb_queue_tail`	x	x
`poll_schedule_timeout.constprop.0 / pollwake`	x	x
`tcp_release_cb / tcp_tasklet_func`	x	x
`tcp_release_cb / tcp_wfree`	x	x
`tick_nohz_next_event / tick_nohz_stop_tick`	x	x
`tick_nohz_stop_tick / tick_nohz_stop_tick`	x	x
`tick_nohz_stop_tick / tick_sched_do_timer`	x	x
`tick_sched_do_timer / tick_sched_do_timer`	x	x
`virtqueue_get_buf_ctx_split+0x62/0x260`	x	-
`xas_clear_mark / xas_find_marked`	x	-

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 netfilter subsystem.

[bmastbergen]

@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 CVE-NOTFOUND can be ignored because our script only looks for CVEs in the kernel's vulns database, so CVE prior to that will show up as not found. I think that applies to a lot of the CVE in this PR. There is one CVE-MISMATCH that you might want to double-check. There is one NOTFOUND which means the script couldn't find the backported sha in the mainline kernel. And there are a handful of FIXES where there are upstream bugfixes for the backported commit that we may want to take a look at. Thanks for the work on this. I know it wasn't straightforward!

um ~/ciq/kernel-src-tree-tools
 % python ./check_kernel_commits.py --repo ~/ciq/kernel-src-tree --pr_branch pvts-mat/ciqlts9_2-CVE-batch-10 --base_branch origin/ciqlts9_2 --check-cves
[CVE-NOTFOUND] PR commit 709f6c7b4aca (netfilter: ctnetlink: fix possible
               refcount leak in ctnetlink_create_conntrack()) references
               CVE-2023-7192 but upstream commit ac4893980bbe has no CVE
               assigned

[FIXES] PR commit 0787373ebc4d (netfilter: conntrack: fix wrong ct->timeout
        value) references upstream commit 73db1b8f2bb6, which has Fixes tags:

    8d1c91850d06 selftests: netfilter: Ignore tainted kernels in interface stress test (Phil Sutter)
    6da5f1b4b4a0 selftests: netfilter: Fix skip of wildcard interface test (Phil Sutter)

[FIXES] PR commit 6ae8fd31e0a9 (netfilter: nf_tables: Introduce
        NFT_MSG_GETRULE_RESET) references upstream commit 8daa8fde3fc3, which
        has Fixes tags:

    ea078ae9108e netfilter: nf_tables: Audit log rule reset (Phil Sutter)

[FIXES] PR commit a4771f950250 (netfilter: nf_tables: add support to destroy
        operation) references upstream commit f80a612dd77c, which has Fixes
        tags:

    a7d5a955bfa8 netfilter: nf_tables: bogus ENOENT when destroying element which does not exist (Pablo Neira Ayuso)

[FIXES] PR commit b39b3ba76ed5 (netfilter: nf_tables: Introduce
        NFT_MSG_GETSETELEM_RESET) references upstream commit 079cd633219d, which
        has Fixes tags:

    4c90bba60c26 netfilter: nf_tables: do not refresh timeout when resetting element (Pablo Neira Ayuso)
    7e9be1124dbe netfilter: nf_tables: Audit log setelem reset (Phil Sutter)

[FIXES] PR commit dfc61266e1a1 (netfilter: nf_tables: integrate pipapo into
        commit protocol) references upstream commit 212ed75dc5fb, which has
        Fixes tags:

    ebd032fa8818 netfilter: nf_tables: do not remove elements if set backend implements .abort (Pablo Neira Ayuso)

[FIXES] PR commit ba24727bdd7b (netfilter: nft_set_pipapo: .walk does not deal
        with generations) references upstream commit 2b84e215f874, which has
        Fixes tags:

    29b359cf6d95 netfilter: nft_set_pipapo: walk over current view on netlink dump (Pablo Neira Ayuso) (CVE-2024-27017)

[FIXES] PR commit 70c31adf2efe (netfilter: nf_tables: drop map element
        references from preparation phase) references upstream commit
        628bd3e49cba, which has Fixes tags:

    e79b47a8615d netfilter: nf_tables: restore set elements when delete set fails (Pablo Neira Ayuso) (CVE-2024-27012)

[FIXES] PR commit 66663eb40599 (netfilter: nf_tables: GC transaction API to
        avoid race with control plane) references upstream commit 5f68718b34a5,
        which has Fixes tags:

    6b1ca88e4bb6 netfilter: nf_tables: skip dead set elements in netlink dump (Pablo Neira Ayuso)
    08e4c8c5919f netfilter: nf_tables: mark newset as dead on transaction abort (Florian Westphal)
    7315dc1e122c netfilter: nf_tables: skip set commit for deleted/destroyed sets (Pablo Neira Ayuso)

[CVE-NOTFOUND] PR commit 66663eb40599 (netfilter: nf_tables: GC transaction API
               to avoid race with control plane) references CVE-2023-4244 but
               upstream commit 5f68718b34a5 has no CVE assigned

[CVE-NOTFOUND] PR commit 37541a7ea34a (netfilter: nf_tables: skip immediate
               deactivate in _PREPARE_ERROR) references CVE-2023-4015 but
               upstream commit 0a771f7b266b has no CVE assigned

[FIXES] PR commit 893218018f7d (netfilter: nf_tables: adapt set backend to use
        GC transaction API) references upstream commit f6c383b8c31a, which has
        Fixes tags:

    7ffc7481153b netfilter: nft_set_hash: skip duplicated elements pending gc run (Pablo Neira Ayuso)
    ffb40fba4045 netfilter: nft_set_pipapo: prefer gfp_kernel allocation (Florian Westphal)

[CVE-NOTFOUND] PR commit 5176fe9324d3 (netfilter: nft_set_hash: mark set element
               as dead when deleting from packet path) references CVE-2023-4244
               but upstream commit c92db3030492 has no CVE assigned

[CVE-NOTFOUND] PR commit ca6e9cf81866 (netfilter: nf_tables: remove busy mark
               and gc batch API) references CVE-2023-4244 but upstream commit
               a2dd0233cbc4 has no CVE assigned

[CVE-NOTFOUND] PR commit a0a91f71d3ea (netfilter: nf_tables: fix false-positive
               lockdep splat) references CVE-2023-4244 but upstream commit
               b9f052dc68f6 has no CVE assigned

[CVE-NOTFOUND] PR commit fa956eac85fe (netfilter: nf_tables: fix kdoc warnings
               after gc rework) references CVE-2023-4244 but upstream commit
               08713cb006b6 has no CVE assigned

[CVE-NOTFOUND] PR commit 136a919f3426 (netfilter: nf_tables: deactivate catchall
               elements in next generation) references CVE-2023-4569 but
               upstream commit 90e5b3462efa has no CVE assigned

[CVE-NOTFOUND] PR commit ca02f6eceafa (netfilter: nf_tables: fix GC transaction
               races with netns and netlink event exit path) references
               CVE-2023-4244 but upstream commit 6a33d8b73dfa has no CVE
               assigned

[CVE-NOTFOUND] PR commit 819d0ed978bd (netfilter: nf_tables: GC transaction race
               with netns dismantle) references CVE-2023-4244 but upstream
               commit 02c6c24402bf has no CVE assigned

[CVE-NOTFOUND] PR commit f6014c33da88 (netfilter: nft_dynset: disallow object
               maps) references CVE-2023-4244 but upstream commit 23185c6aed1f
               has no CVE assigned

[FIXES] PR commit 63df5313037e (netfilter: nf_tables: flush pending destroy work
        before netlink notifier) references upstream commit 2c9f0293280e, which
        has Fixes tags:

    9f6958ba2e90 netfilter: nf_tables: unconditionally flush pending work before notifier (Florian Westphal) (CVE-2024-42109)

[CVE-NOTFOUND] PR commit 63df5313037e (netfilter: nf_tables: flush pending
               destroy work before netlink notifier) references CVE-2023-4244
               but upstream commit 2c9f0293280e has no CVE assigned

[CVE-NOTFOUND] PR commit 9ef4dc2d09ef (netfilter: nf_tables: GC transaction race
               with abort path) references CVE-2023-4244 but upstream commit
               720344340fb9 has no CVE assigned

[CVE-NOTFOUND] PR commit 4572356c3106 (netfilter: nf_tables: use correct lock to
               protect gc_list) references CVE-2023-4244 but upstream commit
               8357bc946a2a has no CVE assigned

[CVE-NOTFOUND] PR commit 3313a980222c (netfilter: nf_tables: fix out of memory
               error handling) references CVE-2023-4244 but upstream commit
               5e1be4cdc98c has no CVE assigned

[CVE-NOTFOUND] PR commit 9744f3c822e0 (netfilter: nf_tables: defer gc run if
               previous batch is still pending) references CVE-2023-4244 but
               upstream commit 8e51830e29e1 has no CVE assigned

[CVE-NOTFOUND] PR commit 89d6ab215ddc (netfilter: nf_tables: disallow rule
               removal from chain binding) references CVE-2023-5197 but upstream
               commit f15f29fd4779 has no CVE assigned

[CVE-NOTFOUND] PR commit e7ebc3994570 (netfilter: nft_set_pipapo: call
               nft_trans_gc_queue_sync() in catchall GC) references
               CVE-2023-4244 but upstream commit 4a9e12ea7e70 has no CVE
               assigned

[CVE-NOTFOUND] PR commit fd09e77c27ef (netfilter: nft_set_rbtree: use read
               spinlock to avoid datapath contention) references CVE-2023-4244
               but upstream commit 96b33300fba8 has no CVE assigned

[CVE-NOTFOUND] PR commit 7bb17203c3ed (netfilter: nft_set_pipapo: stop GC
               iteration if GC transaction allocation fails) references
               CVE-2023-4244 but upstream commit 6d365eabce3c has no CVE
               assigned

[CVE-NOTFOUND] PR commit b5c6baaa7eff (netfilter: nft_set_hash: try later when
               GC hits EAGAIN on iteration) references CVE-2023-4244 but
               upstream commit b079155faae9 has no CVE assigned

[CVE-NOTFOUND] PR commit 80b94426191a (netfilter: nf_tables: disallow element
               removal on anonymous sets) references CVE-2023-4244 but upstream
               commit 23a3bfd4ba7a has no CVE assigned

[CVE-NOTFOUND] PR commit 29b8b9a29b52 (netfilter: nf_tables: disable toggling
               dormant table state more than once) references CVE-2023-4244 but
               upstream commit c9bd26513b3a has no CVE assigned

[CVE-NOTFOUND] PR commit 66a1d3cb56fd (netfilter: nf_tables: nft_set_rbtree: fix
               spurious insertion failure) references CVE-2023-4244 but upstream
               commit 087388278e0f has no CVE assigned

[NOTFOUND] PR commit 172173807588 (netfilter: nf_tables: work around newrule
           after chain binding) references upstream commit d2fd2e46cb93, which
           does not exist in kernel-mainline.

[CVE-NOTFOUND] PR commit 7c0a2d993e49 (netfilter: nft_set_pipapo: no need to
               call pipapo_deactivate() from flush) references CVE-2023-4244 but
               upstream commit 26cec9d4144e has no CVE assigned

[CVE-NOTFOUND] PR commit f21727c8efaf (netfilter: nf_tables: set backend .flush
               always succeeds) references CVE-2023-4244 but upstream commit
               6509a2e410c3 has no CVE assigned

[FIXES] PR commit a35dbfa4febc (netfilter: nf_tables: expose opaque set element
        as struct nft_elem_priv) references upstream commit 9dad402b89e8, which
        has Fixes tags:

    ab0beafd52b9 netfilter: nft_set_pipapo: remove static in nft_pipapo_get() (Pablo Neira Ayuso)

[CVE-NOTFOUND] PR commit a35dbfa4febc (netfilter: nf_tables: expose opaque set
               element as struct nft_elem_priv) references CVE-2023-4244 but
               upstream commit 9dad402b89e8 has no CVE assigned

[CVE-NOTFOUND] PR commit 1b3a51cda6b2 (netfilter: nf_tables: remove catchall
               element in GC sync path) references CVE-2023-6111 but upstream
               commit 93995bf4af2c has no CVE assigned

[CVE-NOTFOUND] PR commit e774e891da6d (netfilter: nf_tables: split async and
               sync catchall in two functions) references CVE-2023-4244 but
               upstream commit 8837ba3e58ea has no CVE assigned

[CVE-NOTFOUND] PR commit b301e6dcf14d (netfilter: ipset: Fix race between
               IPSET_CMD_CREATE and IPSET_CMD_SWAP) references CVE-2023-42756
               but upstream commit 7433b6d2afd5 has no CVE assigned

[CVE-MISMATCH] PR commit ba0c0487c82b (netfilter: nf_tables: mark set as dead
               when unbinding anonymous set with timeout) references
               CVE-2024-26581 but upstream commit 552705a3650b is associated
               with CVE-2024-26643

[bmastbergen]

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.

[bmastbergen]

1721738

This commit is the 'NOTFOUND' and you've made that clear in the commit message. But I wonder if we even want to reference the commit sha at all since it isn't an upstream commit. Right @PlaidCat ?

[pvts-mat]

@pvts-mat I know this is still in draft, but wanted to upload the output from our upstream bug and cve checker script.

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 [CVE-NOTFOUND]:

• Almost 3/4 of the messages refer to CVE-2023-4244 being slapped on commits which aren't formally associated with that CVE but were marked as such simply for the lack of better idea how to describe commits which don't address CVE-2023-4244 directly, but are nevertheless part of its solution. And not all of them could be cve-pre <cve> or cve-bf <cve> for some <cve>. It's a direct consequence of the tagging policy (see the "Tagging policy" section in the PR) - that's why I asked about it on slack. Personally I think what would make most logical sense would be to have them without any cve BUT with the CVE-2023-4244-associated jira VULN-430 property in place. I don't know what makes the most sense from the repo maintanance perspective though.
• Other two instances of CVE-2023-4244 complaining may be due to the fact that the often cited commit associated with CVE-2023-4244 is 3e91b0e, which is a merge commit for an upstream branch addressing this fix. The whole branch was backported, but not the merge branch commit itself, obviously.
• For the rest of CVEs I checked also other sources than https://kernel.dance/ which I used primarily for finding the associations and confirmed that the associated commits are correct.

Here's the detailed breakdown:

PR	cve	upstream	Reason for tagging	A bit deeper dive
709f6c7	CVE-2023-7192	ac48939	Assigned, according to https://kernel.dance/#ac4893980bbe	https://access.redhat.com/security/cve/cve-2023-7192: "https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=ac4893980bbe79ce383daf9a0885666a30fe4c83"
66663eb	CVE-2023-4244	5f68718	Assigned, according to https://kernel.dance/#5f68718b34a5	Merge commit 3e91b0e?
37541a7	CVE-2023-4015	0a771f7	Assigned, according to https://kernel.dance/#0a771f7b266b	https://www.cve.org/CVERecord?id=CVE-2023-4015: "We recommend upgrading past commit 0a771f7"
5176fe9	CVE-2023-4244	c92db30	Tagging policy	-
ca6e9cf	CVE-2023-4244	a2dd023	Tagging policy	-
a0a91f7	CVE-2023-4244	b9f052d	Tagging policy	-
fa956ea	CVE-2023-4244	08713cb	Tagging policy	-
136a919	CVE-2023-4569	90e5b34	Assigned, according to https://kernel.dance/#90e5b3462efa	https://www.cve.org/CVERecord?id=CVE-2023-4569: "https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230812110526.49808-1-fw@strlen.de/"
ca02f6e	CVE-2023-4244	6a33d8b	Assigned, according to https://kernel.dance/#6a33d8b73dfa	Merge commit 3e91b0e?
819d0ed	CVE-2023-4244	02c6c24	Tagging policy	-
f6014c3	CVE-2023-4244	23185c6	Tagging policy	-
63df531	CVE-2023-4244	2c9f029	Tagging policy	-
9ef4dc2	CVE-2023-4244	7203443	Tagging policy	-
4572356	CVE-2023-4244	8357bc9	Tagging policy	-
3313a98	CVE-2023-4244	5e1be4c	Tagging policy	-
9744f3c	CVE-2023-4244	8e51830	Tagging policy	-
89d6ab2	CVE-2023-5197	f15f29f	Assigned, according to https://kernel.dance/#f15f29fd4779	https://www.cve.org/CVERecord?id=CVE-2023-5197: "We recommend upgrading past commit f15f29f."
e7ebc39	CVE-2023-4244	4a9e12e	Tagging policy	-
fd09e77	CVE-2023-4244	96b3330	Tagging policy	-
7bb1720	CVE-2023-4244	6d365ea	Tagging policy	-
b5c6baa	CVE-2023-4244	b079155	Tagging policy	-
80b9442	CVE-2023-4244	23a3bfd	Tagging policy	-
29b8b9a	CVE-2023-4244	c9bd265	Tagging policy	-
66a1d3c	CVE-2023-4244	0873882	Tagging policy	-
7c0a2d9	CVE-2023-4244	26cec9d	Tagging policy	-
f21727c	CVE-2023-4244	6509a2e	Tagging policy	-
a35dbfa	CVE-2023-4244	9dad402	Tagging policy	-
1b3a51c	CVE-2023-6111	93995bf	Assigned, according to https://kernel.dance/#93995bf4af2c	https://www.cve.org/CVERecord?id=CVE-2023-6111: "We recommend upgrading past commit 93995bf."
e774e89	CVE-2023-4244	8837ba3	Tagging policy	-
b301e6d	CVE-2023-42756	7433b6d	Assigned, according to https://kernel.dance/#7433b6d2afd5	https://bugzilla.redhat.com/show_bug.cgi?id=2239848 "Upstream fix: torvalds/linux@7433b6d"

[pvts-mat]

[CVE-MISMATCH]:

[CVE-MISMATCH] PR commit ba0c0487c82b (netfilter: nf_tables: mark set as dead
               when unbinding anonymous set with timeout) references
               CVE-2024-26581 but upstream commit 552705a3650b is associated
               with CVE-2024-26643

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]

[FIXES]

All the fixes reported are addressed in the Commits table in the PR. The Id number in the following table corresponds to the Id number there

Id	Log
	PR commit 6ae8fd3 (…) references upstream commit 8daa8fd, which has Fixes tags:
17	ea078ae `netfilter: nf_tables: Audit log rule reset (Phil Sutter)`
	PR commit a4771f9 (…) references upstream commit f80a612, which has Fixes tags:
14	a7d5a95 `netfilter: nf_tables: bogus ENOENT when destroying element which does not exist (Pablo Neira Ayuso)`
	PR commit b39b3ba (…) references upstream commit 079cd63, which has Fixes tags:
15	4c90bba `netfilter: nf_tables: do not refresh timeout when resetting element (Pablo Neira Ayuso)`
18	7e9be11 `netfilter: nf_tables: Audit log setelem reset (Phil Sutter)`
	PR commit dfc6126 (…) references upstream commit 212ed75, which has Fixes tags:
16	ebd032f `netfilter: nf_tables: do not remove elements if set backend implements .abort (Pablo Neira Ayuso)`
	PR commit ba24727 (…) references upstream commit 2b84e21, which has Fixes tags:
8	29b359c `netfilter: nft_set_pipapo: walk over current view on netlink dump (Pablo Neira Ayuso) (CVE-2024-27017)`
	PR commit 70c31ad (…) references upstream commit 628bd3e, which has Fixes tags:
6	e79b47a `netfilter: nf_tables: restore set elements when delete set fails (Pablo Neira Ayuso) (CVE-2024-27012)`
	PR commit 66663eb (…) references upstream commit 5f68718, which has Fixes tags:
10	6b1ca88 `netfilter: nf_tables: skip dead set elements in netlink dump (Pablo Neira Ayuso)`
11	08e4c8c `netfilter: nf_tables: mark newset as dead on transaction abort (Florian Westphal)`
13	7315dc1 `nf_tables: skip set commit for deleted/destroyed sets (Pablo Neira Ayuso)`
	PR commit 8932180 (…) references upstream commit f6c383b, which has Fixes tags:
3	7ffc748 `netfilter: nft_set_hash: skip duplicated elements pending gc run (Pablo Neira Ayuso)`
12	ffb40fb `netfilter: nft_set_pipapo: prefer gfp_kernel allocation (Florian Westphal)`
	PR commit 63df531 (…) references upstream commit 2c9f029, which has Fixes tags:
5	9f6958b `netfilter: nf_tables: unconditionally flush pending work before notifier (Florian Westphal) (CVE-2024-42109)`
	PR commit a35dbfa (…) references upstream commit 9dad402, which has Fixes tags:
9	ab0beaf `netfilter: nft_set_pipapo: remove static in nft_pipapo_get() (Pablo Neira Ayuso)`

I'll explain the Commits table a bit more in case it's confusing.

Rows 1-19 list commits which are not in the PR, and neither they are in ciqlts9_2 history. They were included there specifically to show what needs to be done yet, but wasn't, for the reasons provided in the Comment column. Those fall roughly into two groups:

• Not backported to 9.4: (9f6958b, 7ffc748, ab0beaf, 6b1ca88, ebd032f, e79b47a, 29b359c) Backporting them would go against the first guidance of this PR (see "Backporting strategy" section). It's not that they cannot or should not be backported just because they weren't for 9.4, but I wanted to focus first on what was backported to 9.4 to have this very useful point of reference untainted. If I mixed in some commits from outside of 9.4 I could get unnecessary conflicts in backporting other 9.4 branches in the future, which leads to the next point.

• Associated branch is long: (08e4c8c, ffb40fb, 7315dc1, a7d5a95, 4c90bba, ea078ae, 7e9be11) This means that the fixing commits were part of a bigger patching efforts in 9.4, similarly to how the CVE-2023-4244 fixing commit 5f68718 was, and that it could make sense to backport them in whole as well (not necessarily, but possibly). At the same time those branches were relatively long and even analyzing them would not be a good idea given how much time this PR already took, let alone backporting them. The branches for each commit are identified in the B column, with details given in the Branches table. For the fixing commits in question there are two of them:

  1. f875124 netfilter: nf_tables: backports from upstream (16 commits, including 5 fixes for this PR)
  2. 3e3b830 audit: backport kernel audit enhancements and fixes up to upstream v6.6 (16 commits, including 2 fixes for this PR)

  I was planning to address them in the next PR, with the first branch being backported in full most probably, and the second one to be evaluated yet. They may also require some prerequisites and their own bugfixes, so they're worthy of a separate PR.

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 netfilter. Well, almost.

[PlaidCat]

1721738

This commit is the 'NOTFOUND' and you've made that clear in the commit message. But I wonder if we even want to reference the commit sha at all since it isn't an upstream commit. Right @PlaidCat ?

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 fedora-ark and debian
See:

• 514cdd8
• 95a753e

[PlaidCat]

These two need reordered

• netfilter: conntrack: fix rmmod double-free race
  • This is missing e6d57e9#diff-d94b0c99e953b37d7db138ce793d51dc3ae22870ff859ab0b490bfd5cab3dc56R383-L384
• netfilter: conntrack: restore IPS_CONFIRMED out of nf_conntrack_hash_check_insert()
  • The above missing line is technically moved in this commit 2cdaa3e#diff-d94b0c99e953b37d7db138ce793d51dc3ae22870ff859ab0b490bfd5cab3dc56R384 into bpf_ct_insert_entry

Order should be:

• netfilter: conntrack: restore IPS_CONFIRMED out of nf_conntrack_hash_check_insert()
• netfilter: conntrack: fix rmmod double-free race

[pvts-mat]

Order should be:

• netfilter: conntrack: restore IPS_CONFIRMED out of nf_conntrack_hash_check_insert()
• netfilter: conntrack: fix rmmod double-free race

Hmm, it seems unlikely that netfilter: conntrack: fix rmmod double-free race should occur after netfilter: conntrack: restore IPS_CONFIRMED out of nf_conntrack_hash_check_insert() in history, given that the latter is the fix of the former

2cdaa3e(kernel-mainline):

Fixes: e6d57e9ff0ae ("netfilter: conntrack: fix rmmod double-free race")

Indeed the 47d4b36(ciqlts9_2) port of e6d57e9(kernel-mainline) doesn't remove the ct->status |= IPS_CONFIRMED line from bpf_ct_insert_entry(…) unlike the original, and even unlike the 5c92dbf(ciqlts9_4) port. The reason is that ciqlts9_2 is missing 0fabd2a(kernel-mainline) (= b10d80f(ciqlts9_4)).

Perhaps upstream-diff should be attached to 47d4b36(ciqlts9_2) despite the clean cherry pick. Do you wish to have it included?

[PlaidCat]

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.

e774e89

[PlaidCat]

Order should be:

• netfilter: conntrack: restore IPS_CONFIRMED out of nf_conntrack_hash_check_insert()
• netfilter: conntrack: fix rmmod double-free race

Hmm, it seems unlikely that netfilter: conntrack: fix rmmod double-free race should occur after netfilter: conntrack: restore IPS_CONFIRMED out of nf_conntrack_hash_check_insert() in history, given that the latter is the fix of the former

2cdaa3e(kernel-mainline):

Fixes: e6d57e9ff0ae ("netfilter: conntrack: fix rmmod double-free race")

Indeed the 47d4b36(ciqlts9_2) port of e6d57e9(kernel-mainline) doesn't remove the ct->status |= IPS_CONFIRMED line from bpf_ct_insert_entry(…) unlike the original, and even unlike the 5c92dbf(ciqlts9_4) port. The reason is that ciqlts9_2 is missing 0fabd2a(kernel-mainline) (= b10d80f(ciqlts9_4)).

Perhaps upstream-diff should be attached to 47d4b36(ciqlts9_2) despite the clean cherry pick. Do you wish to have it included?

No I'm wrong I got mixed up, i missed this part of a9e9413

This is a partial revert of the aforementioned commit to restore
IPS_CONFIRMED.

Let me think about and get back to you on the second part its been several hours looking through this.

[PlaidCat]

Perhaps upstream-diff should be attached to 47d4b36(ciqlts9_2) despite the clean cherry pick. Do you wish to have it included?

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,

[jmaple@devbox pvts-kernel-src-tree]$ find . | xargs grep bpf_ct_set_nat_info 2>/dev/null
[jmaple@devbox pvts-kernel-src-tree]$

So yes lets add the upstream-diff and could you rebase this branch on the latest ciqlts9_2 just to ensure there are no sudden conflicts.

[pvts-mat]

@PlaidCat So how about the "tagging policy"? Do we keep the CVE tags as they are? (I hope not).
Would be good to establish the policy explicitly as the need to apply it will arise soon enough - with the very next netfilter PR.

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).
Also how to jira-tag them?

[PlaidCat]

@PlaidCat So how about the "tagging policy"? Do we keep the CVE tags as they are? (I hope not). Would be good to establish the policy explicitly as the need to apply it will arise soon enough - with the very next netfilter PR.

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). Also how to jira-tag them?

In this sort of case feel free to change those to
subsystem sync netfilter <nvr associated with centos-streams-9>

[jmaple@devbox kernel-src-tree]$ git describe --contains 45aad0524d11f3bba3c790dc5c53a79a8e0574fd
kernel-5.14.0-398.el9~5^2

basically like what we did here:
3844585

subsystem sync netfilter: nf_tables 5.14.0-398.el9
@bmastbergen @shreeya-patel98 @roxanan1996 @kerneltoast do yall have a strong opinion when we're pulling in a lot of CentOS stream fixes for harder CVEs

with the very next netfilter PR.

is there more?? Let me know i'll process this.

Also how to jira-tag them?

I can make one but i'll need all the merges you're basing this off of and I can create a ticket.

[pvts-mat]

In this sort of case feel free to change those to
subsystem sync netfilter

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.

is there more??

Please see the comment #668 (comment).

[pvts-mat]

Also how to jira-tag them?

I can make one but i'll need all the merges you're basing this off of and I can create a ticket.

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 VULN-430. "Driven" may not even be an appropriate word here... this whole PR is in fact a fix for CVE-2023-4244, in a sense that nothing was added which wasn't necessitated by fixing CVE-2023-4244 in a safe way. (With an exception of CVE-2024-26581 - see the "Background" section). All the rest of CVEs are just piggy-backers.

I was asking for a more general rule covering less clear-cut cases, like the next netfilter PR addressing the fixes to this one (again, the #668 (comment)). It wouldn't really be VULN-430 anymore, would it?

[bmastbergen]

In this sort of case feel free to change those to
subsystem sync netfilter

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.

Maybe something like:
subsystem update netfilter: centos-stream-9 cfd9694caf43789

That is a reference to the centos stream 9 merge commit that we are emulating.

Just spitballing

[roxanan1996]

Commit

039e9a24f995d99c1290ae5dc42110eacb0e9c86 netfilter: nf_tables: remove catchall element in GC sync path

is not a clean cherry pick due to missing

netfilter: nf_tables: shrink memory consumption of set elements

[roxanan1996]

Commit

039e9a24f995d99c1290ae5dc42110eacb0e9c86 netfilter: nf_tables: remove catchall element in GC sync path

is not a clean cherry pick due to missing

netfilter: nf_tables: shrink memory consumption of set elements

Similar for

netfilter: nf_tables: split async and sync catchall in two functions

[pvts-mat]

Commit

039e9a24f995d99c1290ae5dc42110eacb0e9c86 netfilter: nf_tables: remove catchall element in GC sync path

is not a clean cherry pick due to missing

netfilter: nf_tables: shrink memory consumption of set elements

Similar for

netfilter: nf_tables: split async and sync catchall in two functions

Those are the commits no. 26, 27 in the Commits table:

Id	mainline	9.4	9.2	Fixes	B	PR	Comment	CVE
26	8837ba3	45aad05	-	27	1	Clean ch-p 9.4	Part of fully backported branch 1	-
27	93995bf	54e39cc	-	39	1	Clean ch-p 9.4	Part of fully backported branch 1	CVE-2023-6111 (F)

Notice the values in the PR column. From the Commits description:

• PR: Whether the commit was included in the PR, and how.
  • …
  • Clean ch-p 9.4: The commit was cherry-picked cleanly from the ciqlts9_4 backported version.
  • …

Also from the "Backporting strategy":

The backport of CVE fixes in this PR relied heavily on the solutions existing in LTS 9.4. Multiple commits were cherry-picked directly from the ciqlts9_4 branch. […] The picks from 9.4 were only used if the picks from mainline generated conflicts.

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 kernel-mainline + ciqlts9_4 collage), although sticking to mainline where possible simplified the ciq-cherry-pick.py-based worflow. The assumed equivalence was based on the lack of CentOS backport's upstream-diff analogue in the commit message. That's quite weak basis, admittedly. I'll launch kerneltoast's interdiff and verify this.

Maybe something like:
subsystem update netfilter: centos-stream-9 cfd9694

That is a reference to the centos stream 9 merge commit that we are emulating.

I like this one. I would add this line even to those commits which do have cve tag, so the block of commits from the same branch can be easily identified. We would have three families of those, to be complete:

subsystem update netfilter: centos-stream-9 cfd9694caf4378958e4f2314024f50a4009015f3

subsystem update netfilter: centos-stream-9 c05955eacf34e0eb9780900ebcab5e398234565d

subsystem update netfilter: centos-stream-9 e4726e3376a4798e40b1bce02252a209fcf0de7c

[roxanan1996]

Commit

039e9a24f995d99c1290ae5dc42110eacb0e9c86 netfilter: nf_tables: remove catchall element in GC sync path

is not a clean cherry pick due to missing

netfilter: nf_tables: shrink memory consumption of set elements

Similar for

netfilter: nf_tables: split async and sync catchall in two functions

Those are the commits no. 26, 27 in the Commits table:
Id mainline 9.4 9.2 Fixes B PR Comment CVE
26 8837ba3 45aad05 - 27 1 Clean ch-p 9.4 Part of fully backported branch 1 -
27 93995bf 54e39cc - 39 1 Clean ch-p 9.4 Part of fully backported branch 1 CVE-2023-6111 (F)

Notice the values in the PR column. From the Commits description:

• PR: Whether the commit was included in the PR, and how.

  • …
  • Clean ch-p 9.4: The commit was cherry-picked cleanly from the ciqlts9_4 backported version.
  • …

Also from the "Backporting strategy":

The backport of CVE fixes in this PR relied heavily on the solutions existing in LTS 9.4. Multiple commits were cherry-picked directly from the ciqlts9_4 branch. […] The picks from 9.4 were only used if the picks from mainline generated conflicts.

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, although sticking to mainline where possible simplified the ciq-cherry-pick.py-based worflow. The assumed equivalence was based on the lack of CentOS backport's upstream-diff analogue in the commit message. That's quite weak basis, admittedly. I'll launch kerneltoast's interdiff and verify this.

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.

[pvts-mat]

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 upstream-diff tags, not the cherry picks from mainstream being unclean. Yes, they should be there, thanks for noticing 👍

[pvts-mat]

I looked into the commits listed in #668 (comment). They all belong to the same CentOS 9 branch c05955e, identified in the PR as (2), and constitute the whole branch, so dropping them would not go against the assumed "Backporting full branches" guideline.

The branch (2) was included because netfilter: nf_tables: add support to destroy operation was a prerequisite for a clean cherry pick of two important commits from branch (1):

• netfilter: nf_tables: report use refcount overflow,
• netfilter: nf_tables: GC transaction API to avoid race with control plane.

Other commits from (2) were only included to keep the branch intact.

However, the conflicts in the two mentioned commits are contextual only and indeed can be easily resolved, the interdiff is actually the same.

I have the compiling patch prepared with the branch (2) completely dropped, which is most probably the same what @kerneltoast arrived at in #668 (comment). This solution may still not be minimal in the sense of

I started going through other commits to see which can be dropped so that we're only left with CVE fixes, CVE fix bugfixes, and required prerequisites.

but it does address everything in #668 (comment) and avoids introducing the features listed in #668 (comment).

It would require repeating the general netfilter tests, but that would be an effort comparable to the tests request in #668 (comment). I think it's a good compromise to continue with this solution. What do you think @kemotaha?

[kemotaha]

To clarify @pvts-mat, Are you suggesting (1) we go forward with the PR as is and test the additional functionality, or (2) we go forward dropping the patches with the additional features and go through the netfilter tests again?

I am fine with either solution. My goal is to make sure. that we have a tested solution and we aren't breaking existing features for customers using them.

[pvts-mat]

To clarify @pvts-mat, Are you suggesting (1) we go forward with the PR as is and test the additional functionality, or (2) we go forward dropping the patches with the additional features and go through the netfilter tests again?

I'm suggesting (2)

[kemotaha]

Sounds good to me. Thanks for the clarification and let's move forward with it.

[pvts-mat]

Pushed the reduced solution and updated the Commits table in the PR description for easier navigation. Three columns play a role here. From the columns description:

• PR / PR1: Whether the commit was included in the PR / PR1, and how, also under which commit.

  • PR: The solution originally proposed in the PR
  • PR1: The reduced solution, as propposed in comment [LTS 9.2] netfilter: CVE-2022-{48641, 49917, 49918}, CVE-2023-{3777, 4015, 4244, 5197, 52620, 52923, 52924, 53549, 53635, 7192} #668 (comment)

  Values:

  • -: Commit not part of the PR.
  • Clean ch-p mainline: The commit was cherry-picked cleanly directly from the kernel-mainline branch.
  • Clean ch-p 9.4: The commit was cherry-picked cleanly from the ciqlts9_4 backported version.
  • Conflict mainline: The cherry pick of the kernel-mainline commit resulted in conflicts and likewise the ciqlts9_4 version. See Conflicts for details about these cases.
  • Contextual conflict ch-p 9.4: The cherry pick of the ciqlts9_4 commit resulted in conflicts, but only contextual (with interdiff remaining the same after resolution).

• ΔPR: Whether the commit in PR1 differs from original PR (either code commited or message or the existence of commit itself)

  • !: There is a change
  • 0: No change
  • -: Doesn't apply

In the following comments the test results will be included.

[pvts-mat]

Functional tests: passed relative

Reference

Same as in the PR

Patch

kselftests–ciqlts9_2-CVE-batch-10–leaner–run1.log
kselftests–ciqlts9_2-CVE-batch-10–leaner–run2.log
kselftests–ciqlts9_2-CVE-batch-10–leaner–run3.log
kselftests–ciqlts9_2-CVE-batch-10–leaner–run4.log
kselftests–ciqlts9_2-CVE-batch-10–leaner–run5.log
kselftests–ciqlts9_2-CVE-batch-10–leaner–run6.log
kselftests–ciqlts9_2-CVE-batch-10–leaner–run7.log
kselftests–ciqlts9_2-CVE-batch-10–leaner–run8.log

Comparison

$ ktests.xsh diff kselftests--ciqlts9_2--run*.log kselftests--ciqlts9_2-CVE-batch-10--leaner--run*.log

Column    File
--------  ----------------------------------------------------
Status0   kselftests--ciqlts9_2--run1.log
Status1   kselftests--ciqlts9_2--run2.log
Status2   kselftests--ciqlts9_2--run3.log
Status3   kselftests--ciqlts9_2-CVE-batch-10--leaner--run1.log
Status4   kselftests--ciqlts9_2-CVE-batch-10--leaner--run2.log
Status5   kselftests--ciqlts9_2-CVE-batch-10--leaner--run3.log
Status6   kselftests--ciqlts9_2-CVE-batch-10--leaner--run4.log
Status7   kselftests--ciqlts9_2-CVE-batch-10--leaner--run5.log
Status8   kselftests--ciqlts9_2-CVE-batch-10--leaner--run6.log
Status9   kselftests--ciqlts9_2-CVE-batch-10--leaner--run7.log
Status10  kselftests--ciqlts9_2-CVE-batch-10--leaner--run8.log

TestCase                              Status0  Status1  Status2  Status3  Status4  Status5  Status6  Status7  Status8  Status9  Status10  Summary
netfilter:conntrack_icmp_related.sh   pass     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass      same
netfilter:conntrack_tcp_unreplied.sh  pass     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass      same
netfilter:conntrack_vrf.sh            pass     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass      same
netfilter:ipip-conntrack-mtu.sh       pass     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass      same
netfilter:ipvs.sh                     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass      same
netfilter:nf_nat_edemux.sh            pass     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass      same
netfilter:nft_conntrack_helper.sh     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass      same
netfilter:nft_fib.sh                  pass     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass      same
netfilter:nft_meta.sh                 pass     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass      same
netfilter:nft_nat.sh                  pass     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass      same
netfilter:nft_queue.sh                pass     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass      same
netfilter:rpath.sh                    pass     pass     pass     pass     pass     pass     pass     pass     pass     pass     pass      same

KFENCE tests: passed

All tests in functional testing were run on kernel with default (enabled) settings for KFENCE:

# CONFIG_KFENCE_DEFERRABLE is not set
# CONFIG_KFENCE_KUNIT_TEST is not set
CONFIG_KFENCE_NUM_OBJECTS=255
CONFIG_KFENCE_SAMPLE_INTERVAL=100
# CONFIG_KFENCE_STATIC_KEYS is not set
CONFIG_KFENCE=y

In case of any KFENCE errors a message like

[  462.929989] ==================================================================
[  462.931009] BUG: KFENCE: out-of-bounds write in trie_get_next_key+0x203/0x2f0
[  462.931009]
…

would occur in the dmesg logs. No such messages were found:

$ sudo ls -lha /var/log/libvirt/qemu/x86_64--test--ciqlts9_2-CVE-batch-10.log

-rw-------. 1 root root 2.0M Dec  3 02:26 /var/log/libvirt/qemu/x86_64--test--ciqlts9_2-CVE-batch-10.log

$ sudo grep --ignore-case kfence /var/log/libvirt/qemu/x86_64--test--ciqlts9_2-CVE-batch-10.log

[    0.162931] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.159006] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.162034] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.163187] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.163219] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.161861] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.161250] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.161250] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.162728] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.175385] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.161631] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.161788] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.161379] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.161460] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.162649] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.162737] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.162248] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.161961] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.162575] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)

[PlaidCat]

I am content with the additional changes

@kerneltoast do you have any more request needing to keep this blocked?

[pvts-mat]

I am content with the additional changes

@kerneltoast do you have any more request needing to keep this blocked?

KASAN & kmemleak tests are still running, though they're fine so far. Should be ready today

[kerneltoast]

The commits look good and I verified that the conflicts from dropping those 6 commits were resolved correctly. 🚢

[pvts-mat]

KASAN tests: passed

The patched kernel PR1 was compiled with the following options changed:

`CONFIG_KASAN`	y
`CONFIG_KASAN_MODULE_TEST`	m
`CONFIG_STACKTRACE`	y
`CONFIG_RANDOMIZE_MEMORY`	n

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–leaner.log

[pvts-mat]

Kmemleak tests: passed

The patched kernel PR1 was compiled with the following options changed:

`CONFIG_DEBUG_KMEMLEAK`	y
`CONFIG_DEBUG_KMEMLEAK_TEST`	y

The tests from functional testing was run 10 times. The script:

[...]

echo clear > /sys/kernel/debug/kmemleak

for ((i=1; i <= $n; i++))
do
    for t in $(tee); do
        echo "${t}:"
        tools/testing/selftests/run_kselftest.sh --test $t
    done <<EOF
netfilter:conntrack_icmp_related.sh
netfilter:conntrack_tcp_unreplied.sh
netfilter:conntrack_vrf.sh
netfilter:ipip-conntrack-mtu.sh
netfilter:ipvs.sh
netfilter:nf_nat_edemux.sh
netfilter:nft_fib.sh
netfilter:nft_meta.sh
netfilter:nft_nat.sh
netfilter:nft_queue.sh
netfilter:rpath.sh
EOF

done

echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak

No memory leaks were found.

kmemleak–ciqlts9_2-CVE-batch-10–leaner.log

[bmastbergen]

Re-ran nftables tests. No regressions with the latest commit set:

brett@lycia ~/ciq/netfilter-test
 % diff -urw nftables-shell-tests-5.14.0-ciqlts9_2-00832a617919+.log nftables-shell-tests-5.14.0-ciqlts9_2-CVE-batch-10-b1df305b0cd7+.log
--- nftables-shell-tests-5.14.0-ciqlts9_2-00832a617919+.log     2025-12-05 12:20:48.119683511 -0500
+++ nftables-shell-tests-5.14.0-ciqlts9_2-CVE-batch-10-b1df305b0cd7+.log        2025-12-05 12:20:48.127683671 -0500
@@ -19,7 +19,8 @@
 I: [OK]                ././testcases/cache/0009_delete_by_handle_incorrect_0
 I: [OK]                ././testcases/cache/0010_implicit_chain_0
+I: [OK]                ././testcases/chains/0001jumps_0
 I: [OK]                ././testcases/chains/0002jumps_1
@@ -100,7 +101,8 @@
 I: [OK]                ././testcases/chains/0040mark_shift_1
 I: [OK]                ././testcases/chains/0041chain_binding_0
+I: [OK]                ././testcases/chains/0042chain_variable_0
 I: [OK]                ././testcases/chains/0043chain_ingress_0
@I: [OK]                ././testcases/transactions/0050rule_1

-I: results: [OK] 304 [FAILED] 6 [TOTAL] 310
+I: results: [OK] 306 [FAILED] 4 [TOTAL] 310
brett@lycia ~/ciq/netfilter-test
 % diff -urw nftables-py-5.14.0-ciqlts9_2-00832a617919+.log nftables-py-5.14.0-ciqlts9_2-CVE-batch-10-b1df305b0cd7+.log
brett@lycia ~/ciq/netfilter-test
 % diff -urw nftables-json_echo-tests-5.14.0-ciqlts9_2-00832a617919+.log nftables-json_echo-tests-5.14.0-ciqlts9_2-CVE-batch-10-b1df305b0cd7+.log
brett@lycia ~/ciq/netfilter-test
 % diff -urw nftables-monitor-tests-5.14.0-ciqlts9_2-00832a617919+.log nftables-monitor-tests-5.14.0-ciqlts9_2-CVE-batch-10-b1df305b0cd7+.log
brett@lycia ~/ciq/netfilter-test
 %

[bmastbergen]

🥌