| Message ID | 20201121062817.3178900-1-eyal.birger@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [net,v2] net/packet: fix packet receive on L3 devices without visible hard header | expand |
On 11/21/20, Eyal Birger <eyal.birger@gmail.com> wrote: > In the patchset merged by commit b9fcf0a0d826 > ("Merge branch 'support-AF_PACKET-for-layer-3-devices'") L3 devices which > did not have header_ops were given one for the purpose of protocol parsing > on af_packet transmit path. > > That change made af_packet receive path regard these devices as having a > visible L3 header and therefore aligned incoming skb->data to point to the > skb's mac_header. Some devices, such as ipip, xfrmi, and others, do not > reset their mac_header prior to ingress and therefore their incoming > packets became malformed. > > Ideally these devices would reset their mac headers, or af_packet would be > able to rely on dev->hard_header_len being 0 for such cases, but it seems > this is not the case. > > Fix by changing af_packet RX ll visibility criteria to include the > existence of a '.create()' header operation, which is used when creating > a device hard header - via dev_hard_header() - by upper layers, and does > not exist in these L3 devices. > > As this predicate may be useful in other situations, add it as a common > dev_has_header() helper in netdevice.h. > > Fixes: b9fcf0a0d826 ("Merge branch > 'support-AF_PACKET-for-layer-3-devices'") > Signed-off-by: Eyal Birger <eyal.birger@gmail.com> > > --- > > v2: > - add common dev_has_header() helper as suggested by Willem de Bruijn > --- > include/linux/netdevice.h | 5 +++++ > net/packet/af_packet.c | 18 +++++++++--------- > 2 files changed, 14 insertions(+), 9 deletions(-) > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h > index 964b494b0e8d..fa275a054f46 100644 > --- a/include/linux/netdevice.h > +++ b/include/linux/netdevice.h > @@ -3137,6 +3137,11 @@ static inline bool dev_validate_header(const struct > net_device *dev, > return false; > } > > +static inline bool dev_has_header(const struct net_device *dev) > +{ > + return dev->header_ops && dev->header_ops->create; > +} > + > typedef int gifconf_func_t(struct net_device * dev, char __user * bufptr, > int len, int size); > int register_gifconf(unsigned int family, gifconf_func_t *gifconf); > diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c > index cefbd50c1090..7a18ffff8551 100644 > --- a/net/packet/af_packet.c > +++ b/net/packet/af_packet.c > @@ -93,8 +93,8 @@ > > /* > Assumptions: > - - If the device has no dev->header_ops, there is no LL header visible > - above the device. In this case, its hard_header_len should be 0. > + - If the device has no dev->header_ops->create, there is no LL header > + visible above the device. In this case, its hard_header_len should be > 0. > The device may prepend its own header internally. In this case, its > needed_headroom should be set to the space needed for it to add its > internal header. > @@ -108,26 +108,26 @@ > On receive: > ----------- > > -Incoming, dev->header_ops != NULL > +Incoming, dev_has_header(dev) == true > mac_header -> ll header > data -> data > > -Outgoing, dev->header_ops != NULL > +Outgoing, dev_has_header(dev) == true > mac_header -> ll header > data -> ll header > > -Incoming, dev->header_ops == NULL > +Incoming, dev_has_header(dev) == false > mac_header -> data > However drivers often make it point to the ll header. > This is incorrect because the ll header should be invisible to us. > data -> data > > -Outgoing, dev->header_ops == NULL > +Outgoing, dev_has_header(dev) == false > mac_header -> data. ll header is invisible to us. > data -> data > > Resume > - If dev->header_ops == NULL we are unable to restore the ll header, > + If dev_has_header(dev) == false we are unable to restore the ll header, > because it is invisible to us. > > > @@ -2069,7 +2069,7 @@ static int packet_rcv(struct sk_buff *skb, struct > net_device *dev, > > skb->dev = dev; > > - if (dev->header_ops) { > + if (dev_has_header(dev)) { > /* The device has an explicit notion of ll header, > * exported to higher levels. > * > @@ -2198,7 +2198,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct > net_device *dev, > if (!net_eq(dev_net(dev), sock_net(sk))) > goto drop; > > - if (dev->header_ops) { > + if (dev_has_header(dev)) { > if (sk->sk_type != SOCK_DGRAM) > skb_push(skb, skb->data - skb_mac_header(skb)); > else if (skb->pkt_type == PACKET_OUTGOING) { Thanks for fixing this. Patch seems correct to me. Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
On Sat, Nov 21, 2020 at 2:56 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > On 11/21/20, Eyal Birger <eyal.birger@gmail.com> wrote: > > In the patchset merged by commit b9fcf0a0d826 > > ("Merge branch 'support-AF_PACKET-for-layer-3-devices'") L3 devices which > > did not have header_ops were given one for the purpose of protocol parsing > > on af_packet transmit path. > > > > That change made af_packet receive path regard these devices as having a > > visible L3 header and therefore aligned incoming skb->data to point to the > > skb's mac_header. Some devices, such as ipip, xfrmi, and others, do not > > reset their mac_header prior to ingress and therefore their incoming > > packets became malformed. > > > > Ideally these devices would reset their mac headers, or af_packet would be > > able to rely on dev->hard_header_len being 0 for such cases, but it seems > > this is not the case. > > > > Fix by changing af_packet RX ll visibility criteria to include the > > existence of a '.create()' header operation, which is used when creating > > a device hard header - via dev_hard_header() - by upper layers, and does > > not exist in these L3 devices. > > > > As this predicate may be useful in other situations, add it as a common > > dev_has_header() helper in netdevice.h. > > > > Fixes: b9fcf0a0d826 ("Merge branch > > 'support-AF_PACKET-for-layer-3-devices'") > > Signed-off-by: Eyal Birger <eyal.birger@gmail.com> > Acked-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Willem de Bruijn <willemb@google.com>
On Sat, 21 Nov 2020 08:23:30 -0500 Willem de Bruijn wrote: > On Sat, Nov 21, 2020 at 2:56 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > > > On 11/21/20, Eyal Birger <eyal.birger@gmail.com> wrote: > > > In the patchset merged by commit b9fcf0a0d826 > > > ("Merge branch 'support-AF_PACKET-for-layer-3-devices'") L3 devices which > > > did not have header_ops were given one for the purpose of protocol parsing > > > on af_packet transmit path. > > > > > > That change made af_packet receive path regard these devices as having a > > > visible L3 header and therefore aligned incoming skb->data to point to the > > > skb's mac_header. Some devices, such as ipip, xfrmi, and others, do not > > > reset their mac_header prior to ingress and therefore their incoming > > > packets became malformed. > > > > > > Ideally these devices would reset their mac headers, or af_packet would be > > > able to rely on dev->hard_header_len being 0 for such cases, but it seems > > > this is not the case. > > > > > > Fix by changing af_packet RX ll visibility criteria to include the > > > existence of a '.create()' header operation, which is used when creating > > > a device hard header - via dev_hard_header() - by upper layers, and does > > > not exist in these L3 devices. > > > > > > As this predicate may be useful in other situations, add it as a common > > > dev_has_header() helper in netdevice.h. > > > > > > Fixes: b9fcf0a0d826 ("Merge branch > > > 'support-AF_PACKET-for-layer-3-devices'") > > > Signed-off-by: Eyal Birger <eyal.birger@gmail.com> > > > Acked-by: Jason A. Donenfeld <Jason@zx2c4.com> > > Acked-by: Willem de Bruijn <willemb@google.com> Applied, thanks!
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 964b494b0e8d..fa275a054f46 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -3137,6 +3137,11 @@ static inline bool dev_validate_header(const struct net_device *dev, return false; } +static inline bool dev_has_header(const struct net_device *dev) +{ + return dev->header_ops && dev->header_ops->create; +} + typedef int gifconf_func_t(struct net_device * dev, char __user * bufptr, int len, int size); int register_gifconf(unsigned int family, gifconf_func_t *gifconf); diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index cefbd50c1090..7a18ffff8551 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -93,8 +93,8 @@ /* Assumptions: - - If the device has no dev->header_ops, there is no LL header visible - above the device. In this case, its hard_header_len should be 0. + - If the device has no dev->header_ops->create, there is no LL header + visible above the device. In this case, its hard_header_len should be 0. The device may prepend its own header internally. In this case, its needed_headroom should be set to the space needed for it to add its internal header. @@ -108,26 +108,26 @@ On receive: ----------- -Incoming, dev->header_ops != NULL +Incoming, dev_has_header(dev) == true mac_header -> ll header data -> data -Outgoing, dev->header_ops != NULL +Outgoing, dev_has_header(dev) == true mac_header -> ll header data -> ll header -Incoming, dev->header_ops == NULL +Incoming, dev_has_header(dev) == false mac_header -> data However drivers often make it point to the ll header. This is incorrect because the ll header should be invisible to us. data -> data -Outgoing, dev->header_ops == NULL +Outgoing, dev_has_header(dev) == false mac_header -> data. ll header is invisible to us. data -> data Resume - If dev->header_ops == NULL we are unable to restore the ll header, + If dev_has_header(dev) == false we are unable to restore the ll header, because it is invisible to us. @@ -2069,7 +2069,7 @@ static int packet_rcv(struct sk_buff *skb, struct net_device *dev, skb->dev = dev; - if (dev->header_ops) { + if (dev_has_header(dev)) { /* The device has an explicit notion of ll header, * exported to higher levels. * @@ -2198,7 +2198,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev, if (!net_eq(dev_net(dev), sock_net(sk))) goto drop; - if (dev->header_ops) { + if (dev_has_header(dev)) { if (sk->sk_type != SOCK_DGRAM) skb_push(skb, skb->data - skb_mac_header(skb)); else if (skb->pkt_type == PACKET_OUTGOING) {
In the patchset merged by commit b9fcf0a0d826 ("Merge branch 'support-AF_PACKET-for-layer-3-devices'") L3 devices which did not have header_ops were given one for the purpose of protocol parsing on af_packet transmit path. That change made af_packet receive path regard these devices as having a visible L3 header and therefore aligned incoming skb->data to point to the skb's mac_header. Some devices, such as ipip, xfrmi, and others, do not reset their mac_header prior to ingress and therefore their incoming packets became malformed. Ideally these devices would reset their mac headers, or af_packet would be able to rely on dev->hard_header_len being 0 for such cases, but it seems this is not the case. Fix by changing af_packet RX ll visibility criteria to include the existence of a '.create()' header operation, which is used when creating a device hard header - via dev_hard_header() - by upper layers, and does not exist in these L3 devices. As this predicate may be useful in other situations, add it as a common dev_has_header() helper in netdevice.h. Fixes: b9fcf0a0d826 ("Merge branch 'support-AF_PACKET-for-layer-3-devices'") Signed-off-by: Eyal Birger <eyal.birger@gmail.com> --- v2: - add common dev_has_header() helper as suggested by Willem de Bruijn --- include/linux/netdevice.h | 5 +++++ net/packet/af_packet.c | 18 +++++++++--------- 2 files changed, 14 insertions(+), 9 deletions(-)