CVE-2024-35840: mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()

CVE-2024-35840: mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()

[Greg Kroah-Hartman]

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()

subflow_finish_connect() uses four fields (backup, join_id, thmac, none)
that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set
in mptcp_parse_option()

The Linux kernel CVE team has assigned CVE-2024-35840 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 5.15.148 with commit 413b91350732
	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 6.1.75 with commit 51e4cb032d49
	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 6.6.14 with commit ad3e8f5c3d5c
	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 6.7.2 with commit 76e8de7273a2
	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 6.8 with commit be1d9d9d38da

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-35840
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/mptcp/subflow.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/413b913507326972135d2977975dbff8b7f2c453
	https://git.kernel.org/stable/c/51e4cb032d49ce094605f27e45eabebc0408893c
	https://git.kernel.org/stable/c/ad3e8f5c3d5c53841046ef7a947c04ad45a20721
	https://git.kernel.org/stable/c/76e8de7273a22a00d27e9b8b7d4d043d6433416a
	https://git.kernel.org/stable/c/be1d9d9d38da922bd4beeec5b6dd821ff5a1dfeb

Re: CVE-2024-35840: mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()

[Michal Hocko]

Hi,
what is the actual security threat here? As far as I can see, the
problem that the commit requested here addresses seems to be rather
functional, rather than responding to an unexpected packet options with
a reset, we actually establish a connection with some garbage parameters
(likely unpredictable). Which is unfortunate but I do not see any
security implications.

On Fri 17-05-24 16:27:13, Greg KH wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()
> 
> subflow_finish_connect() uses four fields (backup, join_id, thmac, none)
> that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set
> in mptcp_parse_option()
> 
> The Linux kernel CVE team has assigned CVE-2024-35840 to this issue.
> 
> 
> Affected and fixed versions
> ===========================
> 
> 	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 5.15.148 with commit 413b91350732
> 	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 6.1.75 with commit 51e4cb032d49
> 	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 6.6.14 with commit ad3e8f5c3d5c
> 	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 6.7.2 with commit 76e8de7273a2
> 	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 6.8 with commit be1d9d9d38da
> 
> Please see https://www.kernel.org for a full list of currently supported
> kernel versions by the kernel community.
> 
> Unaffected versions might change over time as fixes are backported to
> older supported kernel versions.  The official CVE entry at
> 	https://cve.org/CVERecord/?id=CVE-2024-35840
> will be updated if fixes are backported, please check that for the most
> up to date information about this issue.
> 
> 
> Affected files
> ==============
> 
> The file(s) affected by this issue are:
> 	net/mptcp/subflow.c
> 
> 
> Mitigation
> ==========
> 
> The Linux kernel CVE team recommends that you update to the latest
> stable kernel version for this, and many other bugfixes.  Individual
> changes are never tested alone, but rather are part of a larger kernel
> release.  Cherry-picking individual commits is not recommended or
> supported by the Linux kernel community at all.  If however, updating to
> the latest release is impossible, the individual changes to resolve this
> issue can be found at these commits:
> 	https://git.kernel.org/stable/c/413b913507326972135d2977975dbff8b7f2c453
> 	https://git.kernel.org/stable/c/51e4cb032d49ce094605f27e45eabebc0408893c
> 	https://git.kernel.org/stable/c/ad3e8f5c3d5c53841046ef7a947c04ad45a20721
> 	https://git.kernel.org/stable/c/76e8de7273a22a00d27e9b8b7d4d043d6433416a
> 	https://git.kernel.org/stable/c/be1d9d9d38da922bd4beeec5b6dd821ff5a1dfeb

-- 
Michal Hocko
SUSE Labs

Re: CVE-2024-35840: mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()

[Michal Hocko]

On Thu 06-06-24 10:03:59, Michal Hocko wrote:
> Hi,
> what is the actual security threat here? As far as I can see, the
> problem that the commit requested here addresses seems to be rather
> functional, rather than responding to an unexpected packet options with
> a reset, we actually establish a connection with some garbage parameters
> (likely unpredictable). Which is unfortunate but I do not see any
> security implications.

Does the silence mean that there are no actual security implications
here?

> On Fri 17-05-24 16:27:13, Greg KH wrote:
> > Description
> > ===========
> > 
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()
> > 
> > subflow_finish_connect() uses four fields (backup, join_id, thmac, none)
> > that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set
> > in mptcp_parse_option()
> > 
> > The Linux kernel CVE team has assigned CVE-2024-35840 to this issue.
> > 
> > 
> > Affected and fixed versions
> > ===========================
> > 
> > 	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 5.15.148 with commit 413b91350732
> > 	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 6.1.75 with commit 51e4cb032d49
> > 	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 6.6.14 with commit ad3e8f5c3d5c
> > 	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 6.7.2 with commit 76e8de7273a2
> > 	Issue introduced in 5.7 with commit f296234c98a8 and fixed in 6.8 with commit be1d9d9d38da
> > 
> > Please see https://www.kernel.org for a full list of currently supported
> > kernel versions by the kernel community.
> > 
> > Unaffected versions might change over time as fixes are backported to
> > older supported kernel versions.  The official CVE entry at
> > 	https://cve.org/CVERecord/?id=CVE-2024-35840
> > will be updated if fixes are backported, please check that for the most
> > up to date information about this issue.
> > 
> > 
> > Affected files
> > ==============
> > 
> > The file(s) affected by this issue are:
> > 	net/mptcp/subflow.c
> > 
> > 
> > Mitigation
> > ==========
> > 
> > The Linux kernel CVE team recommends that you update to the latest
> > stable kernel version for this, and many other bugfixes.  Individual
> > changes are never tested alone, but rather are part of a larger kernel
> > release.  Cherry-picking individual commits is not recommended or
> > supported by the Linux kernel community at all.  If however, updating to
> > the latest release is impossible, the individual changes to resolve this
> > issue can be found at these commits:
> > 	https://git.kernel.org/stable/c/413b913507326972135d2977975dbff8b7f2c453
> > 	https://git.kernel.org/stable/c/51e4cb032d49ce094605f27e45eabebc0408893c
> > 	https://git.kernel.org/stable/c/ad3e8f5c3d5c53841046ef7a947c04ad45a20721
> > 	https://git.kernel.org/stable/c/76e8de7273a22a00d27e9b8b7d4d043d6433416a
> > 	https://git.kernel.org/stable/c/be1d9d9d38da922bd4beeec5b6dd821ff5a1dfeb
> 
> -- 
> Michal Hocko
> SUSE Labs

-- 
Michal Hocko
SUSE Labs

Re: CVE-2024-35840: mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()

[Greg Kroah-Hartman]

On Mon, Jun 17, 2024 at 01:28:05PM +0200, Michal Hocko wrote:
> On Thu 06-06-24 10:03:59, Michal Hocko wrote:
> > Hi,
> > what is the actual security threat here? As far as I can see, the
> > problem that the commit requested here addresses seems to be rather
> > functional, rather than responding to an unexpected packet options with
> > a reset, we actually establish a connection with some garbage parameters
> > (likely unpredictable). Which is unfortunate but I do not see any
> > security implications.
> 
> Does the silence mean that there are no actual security implications
> here?

Sorry, no, I was traveling and am still trying to catch up with the
pending queue.  Should get to it later today or tomorrow, sorry for the
delay.

greg k-h

Re: CVE-2024-35840: mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()

[Michal Hocko]

On Mon 17-06-24 13:31:13, Greg KH wrote:
> On Mon, Jun 17, 2024 at 01:28:05PM +0200, Michal Hocko wrote:
> > On Thu 06-06-24 10:03:59, Michal Hocko wrote:
> > > Hi,
> > > what is the actual security threat here? As far as I can see, the
> > > problem that the commit requested here addresses seems to be rather
> > > functional, rather than responding to an unexpected packet options with
> > > a reset, we actually establish a connection with some garbage parameters
> > > (likely unpredictable). Which is unfortunate but I do not see any
> > > security implications.
> > 
> > Does the silence mean that there are no actual security implications
> > here?
> 
> Sorry, no, I was traveling and am still trying to catch up with the
> pending queue.  Should get to it later today or tomorrow, sorry for the
> delay.

Thanks!

-- 
Michal Hocko
SUSE Labs

Re: CVE-2024-35840: mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()

[Greg Kroah-Hartman]

On Thu, Jun 06, 2024 at 10:03:54AM +0200, Michal Hocko wrote:
> Hi,
> what is the actual security threat here? As far as I can see, the
> problem that the commit requested here addresses seems to be rather
> functional, rather than responding to an unexpected packet options with
> a reset, we actually establish a connection with some garbage parameters
> (likely unpredictable). Which is unfortunate but I do not see any
> security implications.

Sorry for the delay.  I'm pretty sure this is a data leak as the
"garbage" is coming from other kernel data, and as such, was reviewed by
us as a vulnerability.

Do you not see it as such?

thanks,

greg k-h

Re: CVE-2024-35840: mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()

[Michal Hocko]

On Mon 17-06-24 17:43:10, Greg KH wrote:
> On Thu, Jun 06, 2024 at 10:03:54AM +0200, Michal Hocko wrote:
> > Hi,
> > what is the actual security threat here? As far as I can see, the
> > problem that the commit requested here addresses seems to be rather
> > functional, rather than responding to an unexpected packet options with
> > a reset, we actually establish a connection with some garbage parameters
> > (likely unpredictable). Which is unfortunate but I do not see any
> > security implications.
> 
> Sorry for the delay.  I'm pretty sure this is a data leak as the
> "garbage" is coming from other kernel data, and as such, was reviewed by
> us as a vulnerability.

This is not my area so bear with me, but isn't the garbage coming from a
remote side of the connection so it is just a garbage? I would
understand that a misbehavior on the receiving end could be considered
problematic but I still do not see this happening. Or am I wrong?

-- 
Michal Hocko
SUSE Labs

Re: CVE-2024-35840: mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()

[Greg Kroah-Hartman]

On Mon, Jun 17, 2024 at 05:59:30PM +0200, Michal Hocko wrote:
> On Mon 17-06-24 17:43:10, Greg KH wrote:
> > On Thu, Jun 06, 2024 at 10:03:54AM +0200, Michal Hocko wrote:
> > > Hi,
> > > what is the actual security threat here? As far as I can see, the
> > > problem that the commit requested here addresses seems to be rather
> > > functional, rather than responding to an unexpected packet options with
> > > a reset, we actually establish a connection with some garbage parameters
> > > (likely unpredictable). Which is unfortunate but I do not see any
> > > security implications.
> > 
> > Sorry for the delay.  I'm pretty sure this is a data leak as the
> > "garbage" is coming from other kernel data, and as such, was reviewed by
> > us as a vulnerability.
> 
> This is not my area so bear with me, but isn't the garbage coming from a
> remote side of the connection so it is just a garbage? I would
> understand that a misbehavior on the receiving end could be considered
> problematic but I still do not see this happening. Or am I wrong?

I do not know, I thought it was coming from the local kernel memory.
I'll defer here to the network developers to answer it for sure.

thanks,

greg k-h