In the Linux kernel, the following vulnerability has been resolved: llc: verify mac len before reading mac header LLC reads the mac header with ethhdr without verifying that the skb has an Ethernet header. Syzbot was able to enter llcrcv on a tun device. Tun can insert packets without mac len and with user configurable skb->protocol (passing a tunpi header when not configuring IFFNOPI). BUG: KMSAN: uninit-value in llcstationacsendtestr net/llc/llcstation.c:81 [inline] BUG: KMSAN: uninit-value in llcstationrcv+0x6fb/0x1290 net/llc/llcstation.c:111 llcstationacsendtestr net/llc/llcstation.c:81 [inline] llcstationrcv+0x6fb/0x1290 net/llc/llcstation.c:111 llcrcv+0xc5d/0x14a0 net/llc/llcinput.c:218 _netifreceiveskbonecore net/core/dev.c:5523 [inline] _netifreceiveskb+0x1a6/0x5a0 net/core/dev.c:5637 netifreceiveskbinternal net/core/dev.c:5723 [inline] netifreceiveskb+0x58/0x660 net/core/dev.c:5782 tunrxbatched+0x3ee/0x980 drivers/net/tun.c:1555 tungetuser+0x54c5/0x69c0 drivers/net/tun.c:2002 Add a maclen test before all three ethhdr(skb) calls under net/llc. There are further uses in include/net/llcpdu.h. All these are protected by a test skb->protocol == ETHP8022. Which does not protect against this tun scenario. But the maclen test added in this patch in llcfixupskb will indirectly protect those too. That is called from llcrcv before any other LLC code. It is tempting to just add a blanket maclen check in llcrcv, but not sure whether that could break valid LLC paths that do not assume an Ethernet header. 802.2 LLC may be used on top of non-802.3 protocols in principle. The below referenced commit shows that used to, on top of Token Ring. At least one of the three eth_hdr uses goes back to before the start of git history. But the one that syzbot exercises is introduced in this commit. That commit is old enough (2008), that effectively all stable kernels should receive this.