Bug 2123369

Summary: backport "net: virtio_net_hdr_to_skb: count transport header in UFO"
Product: Red Hat Enterprise Linux 8 Reporter: suresh kumar <surkumar>
Component: kernelAssignee: Ariel Adam <aadam>
kernel sub component: Networking QA Contact: Network QE <network-qe>
Status: CLOSED MIGRATED Docs Contact:
Severity: medium    
Priority: unspecified CC: jiji, kzhang, sukulkar
Version: 8.6Keywords: MigratedToJIRA
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-09-21 13:38:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description suresh kumar 2022-09-01 13:39:23 UTC
Description of problem:

With UDP segmentation offload enabled on Guests, big packets gets dropped before reaching Guest VM.

Version-Release number of selected component (if applicable):
kernel-4.18.0-372.19.1.el8_6

How reproducible:

Always


Below upstream commit is solving this issue and is tested by customer and also locally.

The test kernel was provided to customer over RHEL kernel 4.18.0-372.19.1.el8_6


+++
commit cf9acc90c80ecbee00334aa85d92f4e74014bcff
Author: Jonathan Davies <jonathan.davies>
Date:   Tue Nov 16 17:42:42 2021 +0000

    net: virtio_net_hdr_to_skb: count transport header in UFO
    
    virtio_net_hdr_to_skb does not set the skb's gso_size and gso_type
    correctly for UFO packets received via virtio-net that are a little over
    the GSO size. This can lead to problems elsewhere in the networking
    stack, e.g. ovs_vport_send dropping over-sized packets if gso_size is
    not set.
    
    This is due to the comparison
    
      if (skb->len - p_off > gso_size)
    
    not properly accounting for the transport layer header.
    
    p_off includes the size of the transport layer header (thlen), so
    skb->len - p_off is the size of the TCP/UDP payload.
    
    gso_size is read from the virtio-net header. For UFO, fragmentation
    happens at the IP level so does not need to include the UDP header.
    
    Hence the calculation could be comparing a TCP/UDP payload length with
    an IP payload length, causing legitimate virtio-net packets to have
    lack gso_type/gso_size information.
    
    Example: a UDP packet with payload size 1473 has IP payload size 1481.
    If the guest used UFO, it is not fragmented and the virtio-net header's
    flags indicate that it is a GSO frame (VIRTIO_NET_HDR_GSO_UDP), with
    gso_size = 1480 for an MTU of 1500.  skb->len will be 1515 and p_off
    will be 42, so skb->len - p_off = 1473.  Hence the comparison fails, and
    shinfo->gso_size and gso_type are not set as they should be.

    Instead, add the UDP header length before comparing to gso_size when
    using UFO. In this way, it is the size of the IP payload that is
    compared to gso_size.
    
    Fixes: 6dd912f82680 ("net: check untrusted gso_size at kernel entry")
    Signed-off-by: Jonathan Davies <jonathan.davies>
    Reviewed-by: Willem de Bruijn <willemb>
    Signed-off-by: David S. Miller <davem>
+++


Current workaround is to disable UFO offloading on guest VMs

Comment 1 RHEL Program Management 2023-09-21 13:05:30 UTC
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 2 RHEL Program Management 2023-09-21 13:38:20 UTC
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.