Re: [PATCH net] xfrm: Preserve vlan tags for transport mode software GRO

[Sabrina Dubroca <sd@queasysnail.net>]

2024-04-22, 11:56:09 +0200, Steffen Klassert wrote:
> On Mon, Apr 22, 2024 at 02:56:20PM +1200, Paul Davey wrote:
> > The software GRO path for esp transport mode uses skb_mac_header_rebuild
> > prior to re-injecting the packet via the xfrm_napi_dev.  This only
> > copies skb->mac_len bytes of header which may not be sufficient if the
> > packet contains 802.1Q tags or other VLAN tags.  Worse copying only the
> > initial header will leave a packet marked as being VLAN tagged but
> > without the corresponding tag leading to mangling when it is later
> > untagged.
> > 
> > The VLAN tags are important when receiving the decrypted esp transport
> > mode packet after GRO processing to ensure it is received on the correct
> > interface.
> > 
> > Therefore record the full mac header length in xfrm*_transport_input for
> > later use in correpsonding xfrm*_transport_finish to copy the entire mac
> > header when rebuilding the mac header for GRO.  The skb->data pointer is
> > left pointing skb->mac_header bytes after the start of the mac header as
> > is expected by the network stack and network and transport header
> > offsets reset to this location.
> > 
> > Signed-off-by: Paul Davey <paul.davey@alliedtelesis.co.nz>
> 
> Please add a 'Fixes:' tag so it can be backported to stable.
> 
> > diff --git a/include/net/xfrm.h b/include/net/xfrm.h
> > index 57c743b7e4fe..0331cfecb28b 100644
> > --- a/include/net/xfrm.h
> > +++ b/include/net/xfrm.h
> > @@ -675,6 +675,9 @@ struct xfrm_mode_skb_cb {
> >  
> >  	/* Used by IPv6 only, zero for IPv4. */
> >  	u8 flow_lbl[3];
> > +
> > +	/* Used to keep whole l2 header for transport mode GRO */
> > +	u32 orig_mac_len;
> 
> xfrm_mode_skb_cb has already reached the maximum size of 48 bytes.
> Adding more will overwrite data in the 'struct sk_buff'.

I thought we already had a BUILD_BUG_ON(sizeof(struct
xfrm_mode_skb_cb) > sizeof_field(struct sk_buff, cb)) somewhere, but
apparently not. I guess it's time to add one? (and xfrm_spi_skb_cb, xfrm_skb_cb)

diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 161f535c8b94..afc8b3c881e2 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -793,6 +793,8 @@ void __init xfrm_input_init(void)
 	int err;
 	int i;
 
+	BUILD_BUG_ON(sizeof(struct xfrm_mode_skb_cb) > sizeof_field(struct sk_buff, cb));
+
 	init_dummy_netdev(&xfrm_napi_dev);
 	err = gro_cells_init(&gro_cells, &xfrm_napi_dev);
 	if (err)


Actually it looks like we still have 4B in xfrm_mode_skb_cb:

struct xfrm_mode_skb_cb {
	struct xfrm_tunnel_skb_cb  header;               /*     0    32 */
	__be16                     id;                   /*    32     2 */
	__be16                     frag_off;             /*    34     2 */
	u8                         ihl;                  /*    36     1 */
	u8                         tos;                  /*    37     1 */
	u8                         ttl;                  /*    38     1 */
	u8                         protocol;             /*    39     1 */
	u8                         optlen;               /*    40     1 */
	u8                         flow_lbl[3];          /*    41     3 */

	/* size: 48, cachelines: 1, members: 9 */
	/* padding: 4 */
	/* last cacheline: 48 bytes */
};

flow_lbl ends at 44, so adding orig_mac_len should be fine. I don't
see any config options that would increase the size of
xfrm_mode_skb_cb compared to what I already have.

-- 
Sabrina