CVE-2022-48936: gso: do not skip outer ip header in case of ipip and net_failover

CVE-2022-48936: gso: do not skip outer ip header in case of ipip and net_failover

[Greg Kroah-Hartman]

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

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

gso: do not skip outer ip header in case of ipip and net_failover

We encounter a tcp drop issue in our cloud environment. Packet GROed in
host forwards to a VM virtio_net nic with net_failover enabled. VM acts
as a IPVS LB with ipip encapsulation. The full path like:
host gro -> vm virtio_net rx -> net_failover rx -> ipvs fullnat
 -> ipip encap -> net_failover tx -> virtio_net tx

When net_failover transmits a ipip pkt (gso_type = 0x0103, which means
SKB_GSO_TCPV4, SKB_GSO_DODGY and SKB_GSO_IPXIP4), there is no gso
did because it supports TSO and GSO_IPXIP4. But network_header points to
inner ip header.

Call Trace:
 tcp4_gso_segment        ------> return NULL
 inet_gso_segment        ------> inner iph, network_header points to
 ipip_gso_segment
 inet_gso_segment        ------> outer iph
 skb_mac_gso_segment

Afterwards virtio_net transmits the pkt, only inner ip header is modified.
And the outer one just keeps unchanged. The pkt will be dropped in remote
host.

Call Trace:
 inet_gso_segment        ------> inner iph, outer iph is skipped
 skb_mac_gso_segment
 __skb_gso_segment
 validate_xmit_skb
 validate_xmit_skb_list
 sch_direct_xmit
 __qdisc_run
 __dev_queue_xmit        ------> virtio_net
 dev_hard_start_xmit
 __dev_queue_xmit        ------> net_failover
 ip_finish_output2
 ip_output
 iptunnel_xmit
 ip_tunnel_xmit
 ipip_tunnel_xmit        ------> ipip
 dev_hard_start_xmit
 __dev_queue_xmit
 ip_finish_output2
 ip_output
 ip_forward
 ip_rcv
 __netif_receive_skb_one_core
 netif_receive_skb_internal
 napi_gro_receive
 receive_buf
 virtnet_poll
 net_rx_action

The root cause of this issue is specific with the rare combination of
SKB_GSO_DODGY and a tunnel device that adds an SKB_GSO_ tunnel option.
SKB_GSO_DODGY is set from external virtio_net. We need to reset network
header when callbacks.gso_segment() returns NULL.

This patch also includes ipv6_gso_segment(), considering SIT, etc.

The Linux kernel CVE team has assigned CVE-2022-48936 to this issue.


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

	Issue introduced in 3.13 with commit cb32f511a70b and fixed in 4.9.304 with commit 45d006c2c7ed
	Issue introduced in 3.13 with commit cb32f511a70b and fixed in 4.14.269 with commit 7840e559799a
	Issue introduced in 3.13 with commit cb32f511a70b and fixed in 4.19.232 with commit e9ffbe63f6f3
	Issue introduced in 3.13 with commit cb32f511a70b and fixed in 5.4.182 with commit 2b3cdd70ea5f
	Issue introduced in 3.13 with commit cb32f511a70b and fixed in 5.10.103 with commit dac2490d9ee0
	Issue introduced in 3.13 with commit cb32f511a70b and fixed in 5.15.26 with commit 899e56a1ad43
	Issue introduced in 3.13 with commit cb32f511a70b and fixed in 5.16.12 with commit a739963f4326
	Issue introduced in 3.13 with commit cb32f511a70b and fixed in 5.17 with commit cc20cced0598

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-2022-48936
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/ipv4/af_inet.c
	net/ipv6/ip6_offload.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/45d006c2c7ed7baf1fa258fa7b5bc9923d3a983e
	https://git.kernel.org/stable/c/7840e559799a08a8588ee6de27516a991cb2e5e7
	https://git.kernel.org/stable/c/e9ffbe63f6f32f526a461756309b61c395168d73
	https://git.kernel.org/stable/c/2b3cdd70ea5f5a694f95ea1788393fb3b83071ea
	https://git.kernel.org/stable/c/dac2490d9ee0b89dffc72f1172b8bbeb60eaec39
	https://git.kernel.org/stable/c/899e56a1ad435261812355550ae869d8be3df395
	https://git.kernel.org/stable/c/a739963f43269297c3f438b776194542e2a97499
	https://git.kernel.org/stable/c/cc20cced0598d9a5ff91ae4ab147b3b5e99ee819

Re: CVE-2022-48936: gso: do not skip outer ip header in case of ipip and net_failover

[Michal Koutný]

[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]

On Thu, Aug 22, 2024 at 11:31:37AM GMT, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> We encounter a tcp drop issue in our cloud environment. Packet GROed in
> host forwards to a VM virtio_net nic with net_failover enabled. VM acts
> as a IPVS LB with ipip encapsulation. The full path like:
> host gro -> vm virtio_net rx -> net_failover rx -> ipvs fullnat
>  -> ipip encap -> net_failover tx -> virtio_net tx
> 
> When net_failover transmits a ipip pkt (gso_type = 0x0103, which means
> SKB_GSO_TCPV4, SKB_GSO_DODGY and SKB_GSO_IPXIP4), there is no gso
> did because it supports TSO and GSO_IPXIP4. But network_header points to
> inner ip header.
> 
> Call Trace:
>  tcp4_gso_segment        ------> return NULL
>  inet_gso_segment        ------> inner iph, network_header points to
>  ipip_gso_segment
>  inet_gso_segment        ------> outer iph
>  skb_mac_gso_segment

> Afterwards virtio_net transmits the pkt, only inner ip header is modified.
> And the outer one just keeps unchanged. The pkt will be dropped in remote
> host.

That may appear like a transient connection issue or permanently
impossible connection?

> Call Trace:
>  inet_gso_segment        ------> inner iph, outer iph is skipped
>  skb_mac_gso_segment
>  __skb_gso_segment
>  validate_xmit_skb
>  validate_xmit_skb_list
>  sch_direct_xmit
>  __qdisc_run
>  __dev_queue_xmit        ------> virtio_net
>  dev_hard_start_xmit
>  __dev_queue_xmit        ------> net_failover
>  ip_finish_output2
>  ip_output
>  iptunnel_xmit
>  ip_tunnel_xmit
>  ipip_tunnel_xmit        ------> ipip
>  dev_hard_start_xmit
>  __dev_queue_xmit
>  ip_finish_output2
>  ip_output
>  ip_forward
>  ip_rcv
>  __netif_receive_skb_one_core
>  netif_receive_skb_internal
>  napi_gro_receive
>  receive_buf
>  virtnet_poll
>  net_rx_action
> 
> The root cause of this issue is specific with the rare combination of
> SKB_GSO_DODGY and a tunnel device that adds an SKB_GSO_ tunnel option.
> SKB_GSO_DODGY is set from external virtio_net. We need to reset network
> header when callbacks.gso_segment() returns NULL.

Who's in control of these configuration (who can cause this incorrect
packet being sent)?

> This patch also includes ipv6_gso_segment(), considering SIT, etc.
> 
> The Linux kernel CVE team has assigned CVE-2022-48936 to this issue.

What is the security issue here?

Thanks,
Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: CVE-2022-48936: gso: do not skip outer ip header in case of ipip and net_failover

[Greg Kroah-Hartman]

On Tue, Aug 27, 2024 at 05:02:36PM +0200, Michal Koutný wrote:
> On Thu, Aug 22, 2024 at 11:31:37AM GMT, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > We encounter a tcp drop issue in our cloud environment. Packet GROed in
> > host forwards to a VM virtio_net nic with net_failover enabled. VM acts
> > as a IPVS LB with ipip encapsulation. The full path like:
> > host gro -> vm virtio_net rx -> net_failover rx -> ipvs fullnat
> >  -> ipip encap -> net_failover tx -> virtio_net tx
> > 
> > When net_failover transmits a ipip pkt (gso_type = 0x0103, which means
> > SKB_GSO_TCPV4, SKB_GSO_DODGY and SKB_GSO_IPXIP4), there is no gso
> > did because it supports TSO and GSO_IPXIP4. But network_header points to
> > inner ip header.
> > 
> > Call Trace:
> >  tcp4_gso_segment        ------> return NULL
> >  inet_gso_segment        ------> inner iph, network_header points to
> >  ipip_gso_segment
> >  inet_gso_segment        ------> outer iph
> >  skb_mac_gso_segment
> 
> > Afterwards virtio_net transmits the pkt, only inner ip header is modified.
> > And the outer one just keeps unchanged. The pkt will be dropped in remote
> > host.
> 
> That may appear like a transient connection issue or permanently
> impossible connection?

I don't know.

> > Call Trace:
> >  inet_gso_segment        ------> inner iph, outer iph is skipped
> >  skb_mac_gso_segment
> >  __skb_gso_segment
> >  validate_xmit_skb
> >  validate_xmit_skb_list
> >  sch_direct_xmit
> >  __qdisc_run
> >  __dev_queue_xmit        ------> virtio_net
> >  dev_hard_start_xmit
> >  __dev_queue_xmit        ------> net_failover
> >  ip_finish_output2
> >  ip_output
> >  iptunnel_xmit
> >  ip_tunnel_xmit
> >  ipip_tunnel_xmit        ------> ipip
> >  dev_hard_start_xmit
> >  __dev_queue_xmit
> >  ip_finish_output2
> >  ip_output
> >  ip_forward
> >  ip_rcv
> >  __netif_receive_skb_one_core
> >  netif_receive_skb_internal
> >  napi_gro_receive
> >  receive_buf
> >  virtnet_poll
> >  net_rx_action
> > 
> > The root cause of this issue is specific with the rare combination of
> > SKB_GSO_DODGY and a tunnel device that adds an SKB_GSO_ tunnel option.
> > SKB_GSO_DODGY is set from external virtio_net. We need to reset network
> > header when callbacks.gso_segment() returns NULL.
> 
> Who's in control of these configuration (who can cause this incorrect
> packet being sent)?
> 
> > This patch also includes ipv6_gso_segment(), considering SIT, etc.
> > 
> > The Linux kernel CVE team has assigned CVE-2022-48936 to this issue.
> 
> What is the security issue here?

This was assigned as part of the import of the Linux kernel GSD entries
into CVEs as required by the CVE board of directors (hence the 2022
date).  If you don't feel this should be assigned a CVE, just let me
know and I will be glad to reject it.

thanks,

greg k-h

Re: CVE-2022-48936: gso: do not skip outer ip header in case of ipip and net_failover

[Michal Koutný]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

On Wed, Aug 28, 2024 at 09:30:08AM GMT, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > What is the security issue here?
> 
> This was assigned as part of the import of the Linux kernel GSD entries
> into CVEs as required by the CVE board of directors (hence the 2022
> date).  If you don't feel this should be assigned a CVE, just let me
> know and I will be glad to reject it.

The address of original author bounces back. Willem, could you please
help explaining context of the change? (~the questions in my previous
message).

Thanks,
Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: CVE-2022-48936: gso: do not skip outer ip header in case of ipip and net_failover

[Willem de Bruijn]

On Thu, Aug 29, 2024 at 12:18 PM Michal Koutný <mkoutny@suse.com> wrote:
>
> On Wed, Aug 28, 2024 at 09:30:08AM GMT, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > What is the security issue here?
> >
> > This was assigned as part of the import of the Linux kernel GSD entries
> > into CVEs as required by the CVE board of directors (hence the 2022
> > date).  If you don't feel this should be assigned a CVE, just let me
> > know and I will be glad to reject it.
>
> The address of original author bounces back. Willem, could you please
> help explaining context of the change? (~the questions in my previous
> message).

I don't know why this has a CVE.

The patch reports that the negative effect is a drop due to a corrupted packet.

According to the CVE report this requires both user input with
virtio_net_hdr, which is privileged, and a tunnel device configured,
which again is privileged.

Re: CVE-2022-48936: gso: do not skip outer ip header in case of ipip and net_failover

[Greg Kroah-Hartman]

On Thu, Aug 29, 2024 at 12:53:34PM -0400, Willem de Bruijn wrote:
> On Thu, Aug 29, 2024 at 12:18 PM Michal Koutný <mkoutny@suse.com> wrote:
> >
> > On Wed, Aug 28, 2024 at 09:30:08AM GMT, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > > What is the security issue here?
> > >
> > > This was assigned as part of the import of the Linux kernel GSD entries
> > > into CVEs as required by the CVE board of directors (hence the 2022
> > > date).  If you don't feel this should be assigned a CVE, just let me
> > > know and I will be glad to reject it.
> >
> > The address of original author bounces back. Willem, could you please
> > help explaining context of the change? (~the questions in my previous
> > message).
> 
> I don't know why this has a CVE.
> 
> The patch reports that the negative effect is a drop due to a corrupted packet.
> 
> According to the CVE report this requires both user input with
> virtio_net_hdr, which is privileged, and a tunnel device configured,
> which again is privileged.
> 

Ok, should it be rejected then?  If so, just let me know.

thanks,

greg k-h

Re: CVE-2022-48936: gso: do not skip outer ip header in case of ipip and net_failover

[Willem de Bruijn]

On Thu, Aug 29, 2024 at 12:58 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Thu, Aug 29, 2024 at 12:53:34PM -0400, Willem de Bruijn wrote:
> > On Thu, Aug 29, 2024 at 12:18 PM Michal Koutný <mkoutny@suse.com> wrote:
> > >
> > > On Wed, Aug 28, 2024 at 09:30:08AM GMT, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > > > What is the security issue here?
> > > >
> > > > This was assigned as part of the import of the Linux kernel GSD entries
> > > > into CVEs as required by the CVE board of directors (hence the 2022
> > > > date).  If you don't feel this should be assigned a CVE, just let me
> > > > know and I will be glad to reject it.
> > >
> > > The address of original author bounces back. Willem, could you please
> > > help explaining context of the change? (~the questions in my previous
> > > message).
> >
> > I don't know why this has a CVE.
> >
> > The patch reports that the negative effect is a drop due to a corrupted packet.
> >
> > According to the CVE report this requires both user input with
> > virtio_net_hdr, which is privileged, and a tunnel device configured,
> > which again is privileged.
> >
>
> Ok, should it be rejected then?  If so, just let me know.

It is a legitimate bug fix, definitely stable material.

With the fix backported to all these branches, not sure what, if
anything, more is needed wrt the CVE.

Re: CVE-2022-48936: gso: do not skip outer ip header in case of ipip and net_failover

[Greg Kroah-Hartman]

On Thu, Aug 29, 2024 at 01:07:36PM -0400, Willem de Bruijn wrote:
> On Thu, Aug 29, 2024 at 12:58 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Aug 29, 2024 at 12:53:34PM -0400, Willem de Bruijn wrote:
> > > On Thu, Aug 29, 2024 at 12:18 PM Michal Koutný <mkoutny@suse.com> wrote:
> > > >
> > > > On Wed, Aug 28, 2024 at 09:30:08AM GMT, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > > > > What is the security issue here?
> > > > >
> > > > > This was assigned as part of the import of the Linux kernel GSD entries
> > > > > into CVEs as required by the CVE board of directors (hence the 2022
> > > > > date).  If you don't feel this should be assigned a CVE, just let me
> > > > > know and I will be glad to reject it.
> > > >
> > > > The address of original author bounces back. Willem, could you please
> > > > help explaining context of the change? (~the questions in my previous
> > > > message).
> > >
> > > I don't know why this has a CVE.
> > >
> > > The patch reports that the negative effect is a drop due to a corrupted packet.
> > >
> > > According to the CVE report this requires both user input with
> > > virtio_net_hdr, which is privileged, and a tunnel device configured,
> > > which again is privileged.
> > >
> >
> > Ok, should it be rejected then?  If so, just let me know.
> 
> It is a legitimate bug fix, definitely stable material.
> 
> With the fix backported to all these branches, not sure what, if
> anything, more is needed wrt the CVE.

Ok, for now I'll go revoke this as that feels the safest thing to do at
the moment.

The "frankenkernel" distros can decide if they want to pick this up or
not, everyone sane has had it for years now :)

thanks,

greg k-h

Re: CVE-2022-48936: gso: do not skip outer ip header in case of ipip and net_failover

[Michal Koutný]

On Thu, Aug 29, 2024 at 01:07:36PM GMT, Willem de Bruijn <willemb@google.com> wrote:
> With the fix backported to all these branches, not sure what, if
> anything, more is needed wrt the CVE.

My goal is to maintain some positive signal/noise in the assigned CVEs.

(Also, there are other kernel branches to evaluate as Greg says :-))

On Thu, Aug 29, 2024 at 12:53:34PM GMT, Willem de Bruijn <willemb@google.com> wrote:
> The patch reports that the negative effect is a drop due to a corrupted packet.
> 
> According to the CVE report this requires both user input with
> virtio_net_hdr, which is privileged, and a tunnel device configured,
> which again is privileged.

(Unless inside netns, I assume. Though...)
...that affects only scope of the same user, right? (The effect doesn't
cross boundary of any security domains.)

So far there is nothing in my (incomplete) understadning that would
classify this as a vulnerability (bugfix it is indeed).

Thanks,
Michal