[fips-legacy-8] net/ulp: prevent ULP without clone op from entering the LISTEN status#393
Merged
bmastbergen merged 2 commits intofips-legacy-8-compliant/4.18.0-425.13.1from Jul 3, 2025
Conversation
jira VULN-8789 cve CVE-2023-0461 commit-author Paolo Abeni <pabeni@redhat.com> commit 2c02d41 upstream-diff In inet_csk_listen_start ret is reinitialized to -EADDRINUSE after the new inet_ulp_can_listen check. The upstream change did not do this because err would inevitably be set later in the function in that version. In this kernel there is no future inevitable set of err so we need to set it back to -EADDRINUSE to ensure this function will return -EADDERINUSE if ->get_port() fails. See LT 5.10 commit fdaf885 for the inspiration for this upstream-diff When an ULP-enabled socket enters the LISTEN status, the listener ULP data pointer is copied inside the child/accepted sockets by sk_clone_lock(). The relevant ULP can take care of de-duplicating the context pointer via the clone() operation, but only MPTCP and SMC implement such op. Other ULPs may end-up with a double-free at socket disposal time. We can't simply clear the ULP data at clone time, as TLS replaces the socket ops with custom ones assuming a valid TLS ULP context is available. Instead completely prevent clone-less ULP sockets from entering the LISTEN status. Fixes: 734942c ("tcp: ULP infrastructure") Reported-by: slipper <slipper.alive@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Link: https://lore.kernel.org/r/4b80c3d1dbe3d0ab072f80450c202d9bc88b4b03.1672740602.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 2c02d41) Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
jira VULN-8789 cve-bf CVE-2023-0461 commit-author Paolo Abeni <pabeni@redhat.com> commit 8ccc993 The referenced commit changed the error code returned by the kernel when preventing a non-established socket from attaching the ktls ULP. Before to such a commit, the user-space got ENOTCONN instead of EINVAL. The existing self-tests depend on such error code, and the change caused a failure: RUN global.non_established ... tls.c:1673:non_established:Expected errno (22) == ENOTCONN (107) non_established: Test failed at step #3 FAIL global.non_established In the unlikely event existing applications do the same, address the issue by restoring the prior error code in the above scenario. Note that the only other ULP performing similar checks at init time - smc_ulp_ops - also fails with ENOTCONN when trying to attach the ULP to a non-established socket. Reported-by: Sabrina Dubroca <sd@queasysnail.net> Fixes: 2c02d41 ("net/ulp: prevent ULP without clone op from entering the LISTEN status") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/7bb199e7a93317fb6f8bf8b9b2dc71c18f337cde.1674042685.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 8ccc993) Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com> # Conflicts: # net/ipv4/tcp_ulp.c
2ebbad0
into
fips-legacy-8-compliant/4.18.0-425.13.1
1 check passed
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
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.
jira VULN-8789
cve CVE-2023-0461
First I'll say @pvts-mat did a great write-up on this CVE in this PR #282 so you may want to read that if what I say below doesn't make sense. I'm going to try to give the abbreviated version below....
This CVE was fixed upstream with commit 2c02d41. And later, there was an upstream fix for that commit in commit 8ccc993. Those are the basis for the two commits in this PR. But the backport of commit 2c02d41 requires a change from upstream in order to work correctly on some older kernels. It was actually improperly backported to some stable kernels, and then had to be fixed in another unique, non-upstream based commit. An example of that is LT 5.10 commit fdaf885. Since that commit (or one like it) doesn't exists in the upstream, I chose to incorporate that change into my backport of commit 2c02d41 right off the bat (as described in upstream-diff tag of the commit message). Think of it as the change as it should have originally been backported to stable kernels. Then the upstream fix commit 8ccc993 applied cleanly on top of it. In ciqlts8_6 we actually took the improper backport as it was originally done in stable kernels, and then @pvts-mat fixed that along with 8ccc993 in PR 282. Although the commits to get there are different, we will end up with the same code in fips-legacy-8 and ciqlts8_6. I hope that makes sense.
Build Log
Testing
selftest-4.18.0-425.13.1.el8.ciqfipscompliant.40.1.x86_64.log
selftest-4.18.0-b_f-l-8-c_4.18.0-425.13.1_VULN-8789-25bb22c30da5+.log