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

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