On Thu, Dec 22, 2022 at 10:35:43AM +0200, Tudor Ambarus wrote:
The series is intended for stable@vger.kernel.org # 5.4+
Syzkaller reported the following bug on linux-5.{4, 10, 15}.y: https://syzkaller.appspot.com/bug?id=ce5575575f074c33ff80d104f5baee26f22e95f...
The upstream commit that introduces this bug is: 1ed1d5921139 ("net: skip virtio_net_hdr_set_proto if protocol already set")
Upstream fixes the bug with the following commits, one of which introduces new support: e9d3f80935b6 ("net/af_packet: make sure to pull mac header") dfed913e8b55 ("net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO")
The additional logic and risk backported seems manageable.
The blammed commit introduces a kernel BUG in __skb_gso_segment for AF_PACKET SOCK_RAW GSO VLAN tagged packets. What happens is that virtio_net_hdr_set_proto() exists early as skb->protocol is already set to ETH_P_ALL. Then in packet_parse_headers() skb->protocol is set to ETH_P_8021AD, but neither the network header position is adjusted, nor the mac header is pulled. Thus when we get to validate the xmit skb and enter skb_mac_gso_segment(), skb->mac_len has value 14, but vlan_depth gets updated to 18 after skb_network_protocol() is called. This causes the BUG_ON from __skb_pull(skb, vlan_depth) to be hit, as the mac header has not been pulled yet.
The fixes from upstream backported cleanly without conflicts. I updated the commit message of the first patch to describe the problem encountered, and added Cc, Fixes, Reported-by and Tested-by tags. For the second patch I just added Cc to stable indicating the versions to be fixed, and added my Tested and Signed-off-by tags.
I tested the patches on linux-5.{4, 10, 15}.y.
Eric Dumazet (1): net/af_packet: make sure to pull mac header
Hangbin Liu (1): net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO
net/packet/af_packet.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-)
Now queued up, thanks.
greg k-h