Bug 2260261 - kernel: MPTCP and NetLabel double free vulnerability
Summary: kernel: MPTCP and NetLabel double free vulnerability
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 2260232
TreeView+ depends on / blocked
 
Reported: 2024-01-24 21:38 UTC by Robb Gatica
Modified: 2024-10-24 12:07 UTC (History)
54 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-02-26 15:51:45 UTC
Embargoed:


Attachments (Terms of Use)

Description Robb Gatica 2024-01-24 21:38:20 UTC
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).

Comment 5 Salvatore Bonaccorso 2024-02-26 14:58:30 UTC
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?

Comment 6 Robb Gatica 2024-03-01 21:57:05 UTC
The CVE is now fully removed and should no longer be present in the Red Hat Security Data API


Note You need to log in before you can comment on or make changes to this bug.