[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZiZc6ApkxivqaILg@hog>
Date: Mon, 22 Apr 2024 14:49:44 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Steffen Klassert <steffen.klassert@...unet.com>
Cc: Paul Davey <paul.davey@...iedtelesis.co.nz>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net] xfrm: Preserve vlan tags for transport mode software
GRO
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@...iedtelesis.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
Powered by blists - more mailing lists