Description: While testing a bugfix for a different kernel issue, I inadvertently discovered a way to trigger a double free in the IPv4 networking stack via the use of the MPTCP protocol and labeled networking. A similar bug exists with IPv6, but there it only triggers a refcount underflow, which doesn't lead to a double free. Please see the attached shell reproducers (repro.sh for IPv4 and repro6.sh for IPv6), which include a description of the flaw. The double free requires a few preconditions to be met: 1. SELinux needs to be enabled (can be permissive) and a policy that supports network labeling must be loaded. (This is true in default configuration on Fedora and RHEL. Other Linux Security Modules supporting network labeling, such as SMACK, may also enable this flaw, but I didn't test it.) 2. MPTCP must be available and enabled. (True on Fedora; disabled by default on RHEL-9; unavailable on earlier versions of RHEL.) 3. NetLabel must be configured in a specific way. (Not default on both Fedora and RHEL; can only be done by a privileged user.) I believe the flaw has been present in the Linux kernel since the initial introduction of MPTCP, though I didn't verify this. I'm not aware of any public discussions about this flaw and I haven't shared it with anyone. I also didn't identify the exact root cause and don't have a fix - I'll leave that to MPTCP/networking experts :) I can assist as an SME for SELinux and NetLabel if needed, though the upstream SELinux maintainers will likely have better knowledge than me (and I presume they will also get involved in the security bugfix process at some point).
Two questions: - Is this issue reported upstream to the Linux upstream? - Is the reason that the alias CVE-2024-1627 has been removed that the Linux kernel now is a CNA on its own for Linux? - If the latter, the Red Hat Security Data API still exports that information for the CVE: https://access.redhat.com/hydra/rest/securitydata/cve.json?ids=CVE-2024-1627 can you please drop this as well?
The CVE is now fully removed and should no longer be present in the Red Hat Security Data API