* [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
@ 2021-04-20 9:43 ` Eric Dumazet
0 siblings, 0 replies; 17+ messages in thread
From: Eric Dumazet @ 2021-04-20 9:43 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski
Cc: Xuan Zhuo, Eric Dumazet, Michael S. Tsirkin, netdev,
Mat Martineau, virtualization, Eric Dumazet, syzbot,
Guenter Roeck
From: Eric Dumazet <edumazet@google.com>
KASAN/syzbot had 4 reports, one of them being:
BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]
BUG: KASAN: slab-out-of-bounds in page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
Read of size 12 at addr ffff888014a5f800 by task systemd-udevd/8445
CPU: 0 PID: 8445 Comm: systemd-udevd Not tainted 5.12.0-rc8-next-20210419-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:233
__kasan_report mm/kasan/report.c:419 [inline]
kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:436
check_region_inline mm/kasan/generic.c:180 [inline]
kasan_check_range+0x13d/0x180 mm/kasan/generic.c:186
memcpy+0x20/0x60 mm/kasan/shadow.c:65
memcpy include/linux/fortify-string.h:191 [inline]
page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
receive_mergeable drivers/net/virtio_net.c:1009 [inline]
receive_buf+0x2bc0/0x6250 drivers/net/virtio_net.c:1119
virtnet_receive drivers/net/virtio_net.c:1411 [inline]
virtnet_poll+0x568/0x10b0 drivers/net/virtio_net.c:1516
__napi_poll+0xaf/0x440 net/core/dev.c:6962
napi_poll net/core/dev.c:7029 [inline]
net_rx_action+0x801/0xb40 net/core/dev.c:7116
__do_softirq+0x29b/0x9fe kernel/softirq.c:559
invoke_softirq kernel/softirq.c:433 [inline]
__irq_exit_rcu+0x136/0x200 kernel/softirq.c:637
irq_exit_rcu+0x5/0x20 kernel/softirq.c:649
common_interrupt+0xa4/0xd0 arch/x86/kernel/irq.c:240
Fixes: fb32856b16ad ("virtio-net: page_to_skb() use build_skb when there's sufficient tailroom")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Reported-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtualization@lists.linux-foundation.org
---
drivers/net/virtio_net.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 8cd76037c72481200ea3e8429e9fdfec005dad85..2e28c04aa6351d2b4016f7d277ce104c4970069d 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -385,6 +385,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
struct sk_buff *skb;
struct virtio_net_hdr_mrg_rxbuf *hdr;
unsigned int copy, hdr_len, hdr_padded_len;
+ struct page *page_to_free = NULL;
int tailroom, shinfo_size;
char *p, *hdr_p;
@@ -445,7 +446,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
if (len)
skb_add_rx_frag(skb, 0, page, offset, len, truesize);
else
- put_page(page);
+ page_to_free = page;
goto ok;
}
@@ -479,6 +480,8 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
hdr = skb_vnet_hdr(skb);
memcpy(hdr, hdr_p, hdr_len);
}
+ if (page_to_free)
+ put_page(page_to_free);
if (metasize) {
__skb_pull(skb, metasize);
--
2.31.1.368.gbe11c130af-goog
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
2021-04-20 9:43 ` Eric Dumazet
@ 2021-04-20 10:07 ` Michael S. Tsirkin
-1 siblings, 0 replies; 17+ messages in thread
From: Michael S. Tsirkin @ 2021-04-20 10:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, netdev, Eric Dumazet, syzbot,
Guenter Roeck, Mat Martineau, Xuan Zhuo, Jason Wang,
virtualization
On Tue, Apr 20, 2021 at 02:43:41AM -0700, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> KASAN/syzbot had 4 reports, one of them being:
>
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]
> BUG: KASAN: slab-out-of-bounds in page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
> Read of size 12 at addr ffff888014a5f800 by task systemd-udevd/8445
>
> CPU: 0 PID: 8445 Comm: systemd-udevd Not tainted 5.12.0-rc8-next-20210419-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:233
> __kasan_report mm/kasan/report.c:419 [inline]
> kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:436
> check_region_inline mm/kasan/generic.c:180 [inline]
> kasan_check_range+0x13d/0x180 mm/kasan/generic.c:186
> memcpy+0x20/0x60 mm/kasan/shadow.c:65
> memcpy include/linux/fortify-string.h:191 [inline]
> page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
> receive_mergeable drivers/net/virtio_net.c:1009 [inline]
> receive_buf+0x2bc0/0x6250 drivers/net/virtio_net.c:1119
> virtnet_receive drivers/net/virtio_net.c:1411 [inline]
> virtnet_poll+0x568/0x10b0 drivers/net/virtio_net.c:1516
> __napi_poll+0xaf/0x440 net/core/dev.c:6962
> napi_poll net/core/dev.c:7029 [inline]
> net_rx_action+0x801/0xb40 net/core/dev.c:7116
> __do_softirq+0x29b/0x9fe kernel/softirq.c:559
> invoke_softirq kernel/softirq.c:433 [inline]
> __irq_exit_rcu+0x136/0x200 kernel/softirq.c:637
> irq_exit_rcu+0x5/0x20 kernel/softirq.c:649
> common_interrupt+0xa4/0xd0 arch/x86/kernel/irq.c:240
>
> Fixes: fb32856b16ad ("virtio-net: page_to_skb() use build_skb when there's sufficient tailroom")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Reported-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: virtualization@lists.linux-foundation.org
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/virtio_net.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 8cd76037c72481200ea3e8429e9fdfec005dad85..2e28c04aa6351d2b4016f7d277ce104c4970069d 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -385,6 +385,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> struct sk_buff *skb;
> struct virtio_net_hdr_mrg_rxbuf *hdr;
> unsigned int copy, hdr_len, hdr_padded_len;
> + struct page *page_to_free = NULL;
> int tailroom, shinfo_size;
> char *p, *hdr_p;
>
> @@ -445,7 +446,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> if (len)
> skb_add_rx_frag(skb, 0, page, offset, len, truesize);
> else
> - put_page(page);
> + page_to_free = page;
> goto ok;
> }
>
> @@ -479,6 +480,8 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> hdr = skb_vnet_hdr(skb);
> memcpy(hdr, hdr_p, hdr_len);
> }
> + if (page_to_free)
> + put_page(page_to_free);
>
> if (metasize) {
> __skb_pull(skb, metasize);
> --
> 2.31.1.368.gbe11c130af-goog
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
@ 2021-04-20 10:07 ` Michael S. Tsirkin
0 siblings, 0 replies; 17+ messages in thread
From: Michael S. Tsirkin @ 2021-04-20 10:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: Xuan Zhuo, netdev, Mat Martineau, virtualization, Eric Dumazet,
syzbot, Jakub Kicinski, David S . Miller, Guenter Roeck
On Tue, Apr 20, 2021 at 02:43:41AM -0700, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> KASAN/syzbot had 4 reports, one of them being:
>
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]
> BUG: KASAN: slab-out-of-bounds in page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
> Read of size 12 at addr ffff888014a5f800 by task systemd-udevd/8445
>
> CPU: 0 PID: 8445 Comm: systemd-udevd Not tainted 5.12.0-rc8-next-20210419-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:233
> __kasan_report mm/kasan/report.c:419 [inline]
> kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:436
> check_region_inline mm/kasan/generic.c:180 [inline]
> kasan_check_range+0x13d/0x180 mm/kasan/generic.c:186
> memcpy+0x20/0x60 mm/kasan/shadow.c:65
> memcpy include/linux/fortify-string.h:191 [inline]
> page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
> receive_mergeable drivers/net/virtio_net.c:1009 [inline]
> receive_buf+0x2bc0/0x6250 drivers/net/virtio_net.c:1119
> virtnet_receive drivers/net/virtio_net.c:1411 [inline]
> virtnet_poll+0x568/0x10b0 drivers/net/virtio_net.c:1516
> __napi_poll+0xaf/0x440 net/core/dev.c:6962
> napi_poll net/core/dev.c:7029 [inline]
> net_rx_action+0x801/0xb40 net/core/dev.c:7116
> __do_softirq+0x29b/0x9fe kernel/softirq.c:559
> invoke_softirq kernel/softirq.c:433 [inline]
> __irq_exit_rcu+0x136/0x200 kernel/softirq.c:637
> irq_exit_rcu+0x5/0x20 kernel/softirq.c:649
> common_interrupt+0xa4/0xd0 arch/x86/kernel/irq.c:240
>
> Fixes: fb32856b16ad ("virtio-net: page_to_skb() use build_skb when there's sufficient tailroom")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Reported-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: virtualization@lists.linux-foundation.org
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/virtio_net.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 8cd76037c72481200ea3e8429e9fdfec005dad85..2e28c04aa6351d2b4016f7d277ce104c4970069d 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -385,6 +385,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> struct sk_buff *skb;
> struct virtio_net_hdr_mrg_rxbuf *hdr;
> unsigned int copy, hdr_len, hdr_padded_len;
> + struct page *page_to_free = NULL;
> int tailroom, shinfo_size;
> char *p, *hdr_p;
>
> @@ -445,7 +446,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> if (len)
> skb_add_rx_frag(skb, 0, page, offset, len, truesize);
> else
> - put_page(page);
> + page_to_free = page;
> goto ok;
> }
>
> @@ -479,6 +480,8 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> hdr = skb_vnet_hdr(skb);
> memcpy(hdr, hdr_p, hdr_len);
> }
> + if (page_to_free)
> + put_page(page_to_free);
>
> if (metasize) {
> __skb_pull(skb, metasize);
> --
> 2.31.1.368.gbe11c130af-goog
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
2021-04-20 9:43 ` Eric Dumazet
@ 2021-04-20 13:48 ` Guenter Roeck
-1 siblings, 0 replies; 17+ messages in thread
From: Guenter Roeck @ 2021-04-20 13:48 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller, Jakub Kicinski
Cc: netdev, Eric Dumazet, syzbot, Mat Martineau, Xuan Zhuo,
Jason Wang, Michael S. Tsirkin, virtualization
On 4/20/21 2:43 AM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> KASAN/syzbot had 4 reports, one of them being:
>
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]
> BUG: KASAN: slab-out-of-bounds in page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
> Read of size 12 at addr ffff888014a5f800 by task systemd-udevd/8445
>
> CPU: 0 PID: 8445 Comm: systemd-udevd Not tainted 5.12.0-rc8-next-20210419-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:233
> __kasan_report mm/kasan/report.c:419 [inline]
> kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:436
> check_region_inline mm/kasan/generic.c:180 [inline]
> kasan_check_range+0x13d/0x180 mm/kasan/generic.c:186
> memcpy+0x20/0x60 mm/kasan/shadow.c:65
> memcpy include/linux/fortify-string.h:191 [inline]
> page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
> receive_mergeable drivers/net/virtio_net.c:1009 [inline]
> receive_buf+0x2bc0/0x6250 drivers/net/virtio_net.c:1119
> virtnet_receive drivers/net/virtio_net.c:1411 [inline]
> virtnet_poll+0x568/0x10b0 drivers/net/virtio_net.c:1516
> __napi_poll+0xaf/0x440 net/core/dev.c:6962
> napi_poll net/core/dev.c:7029 [inline]
> net_rx_action+0x801/0xb40 net/core/dev.c:7116
> __do_softirq+0x29b/0x9fe kernel/softirq.c:559
> invoke_softirq kernel/softirq.c:433 [inline]
> __irq_exit_rcu+0x136/0x200 kernel/softirq.c:637
> irq_exit_rcu+0x5/0x20 kernel/softirq.c:649
> common_interrupt+0xa4/0xd0 arch/x86/kernel/irq.c:240
>
> Fixes: fb32856b16ad ("virtio-net: page_to_skb() use build_skb when there's sufficient tailroom")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Reported-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: virtualization@lists.linux-foundation.org
> ---
> drivers/net/virtio_net.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 8cd76037c72481200ea3e8429e9fdfec005dad85..2e28c04aa6351d2b4016f7d277ce104c4970069d 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -385,6 +385,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> struct sk_buff *skb;
> struct virtio_net_hdr_mrg_rxbuf *hdr;
> unsigned int copy, hdr_len, hdr_padded_len;
> + struct page *page_to_free = NULL;
> int tailroom, shinfo_size;
> char *p, *hdr_p;
>
> @@ -445,7 +446,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> if (len)
> skb_add_rx_frag(skb, 0, page, offset, len, truesize);
> else
> - put_page(page);
> + page_to_free = page;
> goto ok;
> }
>
> @@ -479,6 +480,8 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> hdr = skb_vnet_hdr(skb);
> memcpy(hdr, hdr_p, hdr_len);
> }
> + if (page_to_free)
> + put_page(page_to_free);
>
> if (metasize) {
> __skb_pull(skb, metasize);
>
Unfortunately that doesn't fix the problem for me. With this patch applied
on top of next-20210419, I still get the same crash as before:
udhcpc: sending discover^M
Unable to handle kernel paging request at virtual address 0000000000000004^M
udhcpc(169): Oops -1^M
pc = [<0000000000000004>] ra = [<fffffc0000b8c5b8>] ps = 0000 Not tainted^M
pc is at 0x4^M
ra is at napi_gro_receive+0x68/0x150^M
v0 = 0000000000000000 t0 = 0000000000000008 t1 = 0000000000000000^M
t2 = 0000000000000000 t3 = 000000000000000e t4 = 0000000000000038^M
t5 = 000000000000ffff t6 = fffffc00002f298a t7 = fffffc0002c78000^M
s0 = fffffc00010b3ca0 s1 = 0000000000000000 s2 = fffffc00011267e0^M
s3 = 0000000000000000 s4 = fffffc00025f2008 s5 = fffffc00002f2940^M
s6 = fffffc00025f2040^M
a0 = fffffc00025f2008 a1 = fffffc00002f2940 a2 = fffffc0002ca000c^M
a3 = fffffc00000250d0 a4 = 0000000effff0008 a5 = 0000000000000000^M
t8 = fffffc00010b3c80 t9 = fffffc0002ca04cc t10= 0000000000000000^M
t11= 00000000000004c0 pv = fffffc0000b8bc40 at = 0000000000000000^M
gp = fffffc00010f9fb8 sp = 00000000df74db09^M
Disabling lock debugging due to kernel taint^M
Trace:^M
[<fffffc0000b8c5b8>] napi_gro_receive+0x68/0x150^M
[<fffffc00009b409c>] receive_buf+0x50c/0x1b80^M
[<fffffc00009b58b8>] virtnet_poll+0x1a8/0x5b0^M
[<fffffc00009b58ec>] virtnet_poll+0x1dc/0x5b0^M
[<fffffc0000b8d17c>] __napi_poll+0x4c/0x270^M
[<fffffc0000b8d670>] net_rx_action+0x130/0x2c0^M
[<fffffc0000bd6cb0>] sch_direct_xmit+0x170/0x360^M
[<fffffc0000bd7000>] __qdisc_run+0x160/0x6c0^M
[<fffffc0000337b64>] do_softirq+0xa4/0xd0^M
[<fffffc0000337ca4>] __local_bh_enable_ip+0x114/0x120^M
[<fffffc0000b89554>] __dev_queue_xmit+0x484/0xa60^M
[<fffffc0000cd072c>] packet_sendmsg+0xe7c/0x1ba0^M
[<fffffc0000b53338>] __sys_sendto+0xf8/0x170^M
[<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
[<fffffc0000a9bf7c>] ehci_irq+0x2cc/0x5c0^M
[<fffffc0000a71334>] usb_hcd_irq+0x34/0x50^M
[<fffffc0000b521bc>] move_addr_to_kernel+0x3c/0x60^M
[<fffffc0000b532e4>] __sys_sendto+0xa4/0x170^M
[<fffffc0000b533d4>] sys_sendto+0x24/0x40^M
[<fffffc0000cfea38>] _raw_spin_lock+0x18/0x30^M
[<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
[<fffffc0000325298>] clipper_enable_irq+0x98/0x100^M
[<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
[<fffffc0000311514>] entSys+0xa4/0xc0^M
^M
Code:^M
00000000 ^M
00063301 ^M
00000897 ^M
00001111 ^M
00001672 ^M
^M
Kernel panic - not syncing: Aiee, killing interrupt handler!^M
Guenter
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
@ 2021-04-20 13:48 ` Guenter Roeck
0 siblings, 0 replies; 17+ messages in thread
From: Guenter Roeck @ 2021-04-20 13:48 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller, Jakub Kicinski
Cc: Xuan Zhuo, Michael S. Tsirkin, netdev, Mat Martineau,
virtualization, Eric Dumazet, syzbot
On 4/20/21 2:43 AM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> KASAN/syzbot had 4 reports, one of them being:
>
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]
> BUG: KASAN: slab-out-of-bounds in page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
> Read of size 12 at addr ffff888014a5f800 by task systemd-udevd/8445
>
> CPU: 0 PID: 8445 Comm: systemd-udevd Not tainted 5.12.0-rc8-next-20210419-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:233
> __kasan_report mm/kasan/report.c:419 [inline]
> kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:436
> check_region_inline mm/kasan/generic.c:180 [inline]
> kasan_check_range+0x13d/0x180 mm/kasan/generic.c:186
> memcpy+0x20/0x60 mm/kasan/shadow.c:65
> memcpy include/linux/fortify-string.h:191 [inline]
> page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
> receive_mergeable drivers/net/virtio_net.c:1009 [inline]
> receive_buf+0x2bc0/0x6250 drivers/net/virtio_net.c:1119
> virtnet_receive drivers/net/virtio_net.c:1411 [inline]
> virtnet_poll+0x568/0x10b0 drivers/net/virtio_net.c:1516
> __napi_poll+0xaf/0x440 net/core/dev.c:6962
> napi_poll net/core/dev.c:7029 [inline]
> net_rx_action+0x801/0xb40 net/core/dev.c:7116
> __do_softirq+0x29b/0x9fe kernel/softirq.c:559
> invoke_softirq kernel/softirq.c:433 [inline]
> __irq_exit_rcu+0x136/0x200 kernel/softirq.c:637
> irq_exit_rcu+0x5/0x20 kernel/softirq.c:649
> common_interrupt+0xa4/0xd0 arch/x86/kernel/irq.c:240
>
> Fixes: fb32856b16ad ("virtio-net: page_to_skb() use build_skb when there's sufficient tailroom")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Reported-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: virtualization@lists.linux-foundation.org
> ---
> drivers/net/virtio_net.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 8cd76037c72481200ea3e8429e9fdfec005dad85..2e28c04aa6351d2b4016f7d277ce104c4970069d 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -385,6 +385,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> struct sk_buff *skb;
> struct virtio_net_hdr_mrg_rxbuf *hdr;
> unsigned int copy, hdr_len, hdr_padded_len;
> + struct page *page_to_free = NULL;
> int tailroom, shinfo_size;
> char *p, *hdr_p;
>
> @@ -445,7 +446,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> if (len)
> skb_add_rx_frag(skb, 0, page, offset, len, truesize);
> else
> - put_page(page);
> + page_to_free = page;
> goto ok;
> }
>
> @@ -479,6 +480,8 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> hdr = skb_vnet_hdr(skb);
> memcpy(hdr, hdr_p, hdr_len);
> }
> + if (page_to_free)
> + put_page(page_to_free);
>
> if (metasize) {
> __skb_pull(skb, metasize);
>
Unfortunately that doesn't fix the problem for me. With this patch applied
on top of next-20210419, I still get the same crash as before:
udhcpc: sending discover^M
Unable to handle kernel paging request at virtual address 0000000000000004^M
udhcpc(169): Oops -1^M
pc = [<0000000000000004>] ra = [<fffffc0000b8c5b8>] ps = 0000 Not tainted^M
pc is at 0x4^M
ra is at napi_gro_receive+0x68/0x150^M
v0 = 0000000000000000 t0 = 0000000000000008 t1 = 0000000000000000^M
t2 = 0000000000000000 t3 = 000000000000000e t4 = 0000000000000038^M
t5 = 000000000000ffff t6 = fffffc00002f298a t7 = fffffc0002c78000^M
s0 = fffffc00010b3ca0 s1 = 0000000000000000 s2 = fffffc00011267e0^M
s3 = 0000000000000000 s4 = fffffc00025f2008 s5 = fffffc00002f2940^M
s6 = fffffc00025f2040^M
a0 = fffffc00025f2008 a1 = fffffc00002f2940 a2 = fffffc0002ca000c^M
a3 = fffffc00000250d0 a4 = 0000000effff0008 a5 = 0000000000000000^M
t8 = fffffc00010b3c80 t9 = fffffc0002ca04cc t10= 0000000000000000^M
t11= 00000000000004c0 pv = fffffc0000b8bc40 at = 0000000000000000^M
gp = fffffc00010f9fb8 sp = 00000000df74db09^M
Disabling lock debugging due to kernel taint^M
Trace:^M
[<fffffc0000b8c5b8>] napi_gro_receive+0x68/0x150^M
[<fffffc00009b409c>] receive_buf+0x50c/0x1b80^M
[<fffffc00009b58b8>] virtnet_poll+0x1a8/0x5b0^M
[<fffffc00009b58ec>] virtnet_poll+0x1dc/0x5b0^M
[<fffffc0000b8d17c>] __napi_poll+0x4c/0x270^M
[<fffffc0000b8d670>] net_rx_action+0x130/0x2c0^M
[<fffffc0000bd6cb0>] sch_direct_xmit+0x170/0x360^M
[<fffffc0000bd7000>] __qdisc_run+0x160/0x6c0^M
[<fffffc0000337b64>] do_softirq+0xa4/0xd0^M
[<fffffc0000337ca4>] __local_bh_enable_ip+0x114/0x120^M
[<fffffc0000b89554>] __dev_queue_xmit+0x484/0xa60^M
[<fffffc0000cd072c>] packet_sendmsg+0xe7c/0x1ba0^M
[<fffffc0000b53338>] __sys_sendto+0xf8/0x170^M
[<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
[<fffffc0000a9bf7c>] ehci_irq+0x2cc/0x5c0^M
[<fffffc0000a71334>] usb_hcd_irq+0x34/0x50^M
[<fffffc0000b521bc>] move_addr_to_kernel+0x3c/0x60^M
[<fffffc0000b532e4>] __sys_sendto+0xa4/0x170^M
[<fffffc0000b533d4>] sys_sendto+0x24/0x40^M
[<fffffc0000cfea38>] _raw_spin_lock+0x18/0x30^M
[<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
[<fffffc0000325298>] clipper_enable_irq+0x98/0x100^M
[<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
[<fffffc0000311514>] entSys+0xa4/0xc0^M
^M
Code:^M
00000000 ^M
00063301 ^M
00000897 ^M
00001111 ^M
00001672 ^M
^M
Kernel panic - not syncing: Aiee, killing interrupt handler!^M
Guenter
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
2021-04-20 13:48 ` Guenter Roeck
(?)
@ 2021-04-20 14:00 ` Eric Dumazet
2021-04-20 15:42 ` Guenter Roeck
-1 siblings, 1 reply; 17+ messages in thread
From: Eric Dumazet @ 2021-04-20 14:00 UTC (permalink / raw)
To: Guenter Roeck
Cc: Eric Dumazet, David S . Miller, Jakub Kicinski, netdev, syzbot,
Mat Martineau, Xuan Zhuo, Jason Wang, Michael S. Tsirkin,
virtualization
On Tue, Apr 20, 2021 at 3:48 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 4/20/21 2:43 AM, Eric Dumazet wrote:
> >
>
> Unfortunately that doesn't fix the problem for me. With this patch applied
> on top of next-20210419, I still get the same crash as before:
>
> udhcpc: sending discover^M
> Unable to handle kernel paging request at virtual address 0000000000000004^M
> udhcpc(169): Oops -1^M
> pc = [<0000000000000004>] ra = [<fffffc0000b8c5b8>] ps = 0000 Not tainted^M
> pc is at 0x4^M
> ra is at napi_gro_receive+0x68/0x150^M
> v0 = 0000000000000000 t0 = 0000000000000008 t1 = 0000000000000000^M
> t2 = 0000000000000000 t3 = 000000000000000e t4 = 0000000000000038^M
> t5 = 000000000000ffff t6 = fffffc00002f298a t7 = fffffc0002c78000^M
> s0 = fffffc00010b3ca0 s1 = 0000000000000000 s2 = fffffc00011267e0^M
> s3 = 0000000000000000 s4 = fffffc00025f2008 s5 = fffffc00002f2940^M
> s6 = fffffc00025f2040^M
> a0 = fffffc00025f2008 a1 = fffffc00002f2940 a2 = fffffc0002ca000c^M
> a3 = fffffc00000250d0 a4 = 0000000effff0008 a5 = 0000000000000000^M
> t8 = fffffc00010b3c80 t9 = fffffc0002ca04cc t10= 0000000000000000^M
> t11= 00000000000004c0 pv = fffffc0000b8bc40 at = 0000000000000000^M
> gp = fffffc00010f9fb8 sp = 00000000df74db09^M
> Disabling lock debugging due to kernel taint^M
> Trace:^M
> [<fffffc0000b8c5b8>] napi_gro_receive+0x68/0x150^M
> [<fffffc00009b409c>] receive_buf+0x50c/0x1b80^M
> [<fffffc00009b58b8>] virtnet_poll+0x1a8/0x5b0^M
> [<fffffc00009b58ec>] virtnet_poll+0x1dc/0x5b0^M
> [<fffffc0000b8d17c>] __napi_poll+0x4c/0x270^M
> [<fffffc0000b8d670>] net_rx_action+0x130/0x2c0^M
> [<fffffc0000bd6cb0>] sch_direct_xmit+0x170/0x360^M
> [<fffffc0000bd7000>] __qdisc_run+0x160/0x6c0^M
> [<fffffc0000337b64>] do_softirq+0xa4/0xd0^M
> [<fffffc0000337ca4>] __local_bh_enable_ip+0x114/0x120^M
> [<fffffc0000b89554>] __dev_queue_xmit+0x484/0xa60^M
> [<fffffc0000cd072c>] packet_sendmsg+0xe7c/0x1ba0^M
> [<fffffc0000b53338>] __sys_sendto+0xf8/0x170^M
> [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> [<fffffc0000a9bf7c>] ehci_irq+0x2cc/0x5c0^M
> [<fffffc0000a71334>] usb_hcd_irq+0x34/0x50^M
> [<fffffc0000b521bc>] move_addr_to_kernel+0x3c/0x60^M
> [<fffffc0000b532e4>] __sys_sendto+0xa4/0x170^M
> [<fffffc0000b533d4>] sys_sendto+0x24/0x40^M
> [<fffffc0000cfea38>] _raw_spin_lock+0x18/0x30^M
> [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> [<fffffc0000325298>] clipper_enable_irq+0x98/0x100^M
> [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> [<fffffc0000311514>] entSys+0xa4/0xc0^M
OK, it would be nice if you could get line number from this stack trace.
(scripts/decode_stacktrace.sh is your friend)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
2021-04-20 14:00 ` Eric Dumazet
@ 2021-04-20 15:42 ` Guenter Roeck
0 siblings, 0 replies; 17+ messages in thread
From: Guenter Roeck @ 2021-04-20 15:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, David S . Miller, Jakub Kicinski, netdev, syzbot,
Mat Martineau, Xuan Zhuo, Jason Wang, Michael S. Tsirkin,
virtualization
On Tue, Apr 20, 2021 at 04:00:07PM +0200, Eric Dumazet wrote:
> On Tue, Apr 20, 2021 at 3:48 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On 4/20/21 2:43 AM, Eric Dumazet wrote:
>
> > >
> >
> > Unfortunately that doesn't fix the problem for me. With this patch applied
> > on top of next-20210419, I still get the same crash as before:
> >
> > udhcpc: sending discover^M
> > Unable to handle kernel paging request at virtual address 0000000000000004^M
> > udhcpc(169): Oops -1^M
> > pc = [<0000000000000004>] ra = [<fffffc0000b8c5b8>] ps = 0000 Not tainted^M
> > pc is at 0x4^M
> > ra is at napi_gro_receive+0x68/0x150^M
> > v0 = 0000000000000000 t0 = 0000000000000008 t1 = 0000000000000000^M
> > t2 = 0000000000000000 t3 = 000000000000000e t4 = 0000000000000038^M
> > t5 = 000000000000ffff t6 = fffffc00002f298a t7 = fffffc0002c78000^M
> > s0 = fffffc00010b3ca0 s1 = 0000000000000000 s2 = fffffc00011267e0^M
> > s3 = 0000000000000000 s4 = fffffc00025f2008 s5 = fffffc00002f2940^M
> > s6 = fffffc00025f2040^M
> > a0 = fffffc00025f2008 a1 = fffffc00002f2940 a2 = fffffc0002ca000c^M
> > a3 = fffffc00000250d0 a4 = 0000000effff0008 a5 = 0000000000000000^M
> > t8 = fffffc00010b3c80 t9 = fffffc0002ca04cc t10= 0000000000000000^M
> > t11= 00000000000004c0 pv = fffffc0000b8bc40 at = 0000000000000000^M
> > gp = fffffc00010f9fb8 sp = 00000000df74db09^M
> > Disabling lock debugging due to kernel taint^M
> > Trace:^M
> > [<fffffc0000b8c5b8>] napi_gro_receive+0x68/0x150^M
> > [<fffffc00009b409c>] receive_buf+0x50c/0x1b80^M
> > [<fffffc00009b58b8>] virtnet_poll+0x1a8/0x5b0^M
> > [<fffffc00009b58ec>] virtnet_poll+0x1dc/0x5b0^M
> > [<fffffc0000b8d17c>] __napi_poll+0x4c/0x270^M
> > [<fffffc0000b8d670>] net_rx_action+0x130/0x2c0^M
> > [<fffffc0000bd6cb0>] sch_direct_xmit+0x170/0x360^M
> > [<fffffc0000bd7000>] __qdisc_run+0x160/0x6c0^M
> > [<fffffc0000337b64>] do_softirq+0xa4/0xd0^M
> > [<fffffc0000337ca4>] __local_bh_enable_ip+0x114/0x120^M
> > [<fffffc0000b89554>] __dev_queue_xmit+0x484/0xa60^M
> > [<fffffc0000cd072c>] packet_sendmsg+0xe7c/0x1ba0^M
> > [<fffffc0000b53338>] __sys_sendto+0xf8/0x170^M
> > [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> > [<fffffc0000a9bf7c>] ehci_irq+0x2cc/0x5c0^M
> > [<fffffc0000a71334>] usb_hcd_irq+0x34/0x50^M
> > [<fffffc0000b521bc>] move_addr_to_kernel+0x3c/0x60^M
> > [<fffffc0000b532e4>] __sys_sendto+0xa4/0x170^M
> > [<fffffc0000b533d4>] sys_sendto+0x24/0x40^M
> > [<fffffc0000cfea38>] _raw_spin_lock+0x18/0x30^M
> > [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> > [<fffffc0000325298>] clipper_enable_irq+0x98/0x100^M
> > [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> > [<fffffc0000311514>] entSys+0xa4/0xc0^M
>
> OK, it would be nice if you could get line number from this stack trace.
>
Here you are:
napi_gro_receive (net/core/dev.c:6196)
receive_buf (drivers/net/virtio_net.c:1150)
virtnet_poll (drivers/net/virtio_net.c:1414 drivers/net/virtio_net.c:1519)
clipper_srm_device_interrupt (arch/alpha/kernel/sys_dp264.c:256)
virtnet_poll (drivers/net/virtio_net.c:1413 drivers/net/virtio_net.c:1519)
__napi_poll (net/core/dev.c:6962)
net_rx_action (net/core/dev.c:7029 net/core/dev.c:7116)
__qdisc_run (net/sched/sch_generic.c:376 net/sched/sch_generic.c:384)
do_softirq (./include/asm-generic/softirq_stack.h:10 kernel/softirq.c:460 kernel/softirq.c:447)
__local_bh_enable_ip (kernel/softirq.c:384)
__dev_queue_xmit (./include/linux/bottom_half.h:32 ./include/linux/rcupdate.h:746 net/core/dev.c:4272)
packet_sendmsg (net/packet/af_packet.c:3009 net/packet/af_packet.c:3034)
__sys_sendto (net/socket.c:654 net/socket.c:674 net/socket.c:1977)
__d_alloc (fs/dcache.c:1744)
packet_create (net/packet/af_packet.c:1192 net/packet/af_packet.c:3296)
move_addr_to_kernel (./include/linux/uaccess.h:192 net/socket.c:198 net/socket.c:192)
__sys_sendto (net/socket.c:1968)
sys_sendto (net/socket.c:1989 net/socket.c:1985)
sys_bind (net/socket.c:1648 net/socket.c:1646)
entSys (arch/alpha/kernel/entry.S:477)
Guenter
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
@ 2021-04-20 15:42 ` Guenter Roeck
0 siblings, 0 replies; 17+ messages in thread
From: Guenter Roeck @ 2021-04-20 15:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Xuan Zhuo, Eric Dumazet, Michael S. Tsirkin, netdev,
Mat Martineau, virtualization, syzbot, Jakub Kicinski,
David S . Miller
On Tue, Apr 20, 2021 at 04:00:07PM +0200, Eric Dumazet wrote:
> On Tue, Apr 20, 2021 at 3:48 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On 4/20/21 2:43 AM, Eric Dumazet wrote:
>
> > >
> >
> > Unfortunately that doesn't fix the problem for me. With this patch applied
> > on top of next-20210419, I still get the same crash as before:
> >
> > udhcpc: sending discover^M
> > Unable to handle kernel paging request at virtual address 0000000000000004^M
> > udhcpc(169): Oops -1^M
> > pc = [<0000000000000004>] ra = [<fffffc0000b8c5b8>] ps = 0000 Not tainted^M
> > pc is at 0x4^M
> > ra is at napi_gro_receive+0x68/0x150^M
> > v0 = 0000000000000000 t0 = 0000000000000008 t1 = 0000000000000000^M
> > t2 = 0000000000000000 t3 = 000000000000000e t4 = 0000000000000038^M
> > t5 = 000000000000ffff t6 = fffffc00002f298a t7 = fffffc0002c78000^M
> > s0 = fffffc00010b3ca0 s1 = 0000000000000000 s2 = fffffc00011267e0^M
> > s3 = 0000000000000000 s4 = fffffc00025f2008 s5 = fffffc00002f2940^M
> > s6 = fffffc00025f2040^M
> > a0 = fffffc00025f2008 a1 = fffffc00002f2940 a2 = fffffc0002ca000c^M
> > a3 = fffffc00000250d0 a4 = 0000000effff0008 a5 = 0000000000000000^M
> > t8 = fffffc00010b3c80 t9 = fffffc0002ca04cc t10= 0000000000000000^M
> > t11= 00000000000004c0 pv = fffffc0000b8bc40 at = 0000000000000000^M
> > gp = fffffc00010f9fb8 sp = 00000000df74db09^M
> > Disabling lock debugging due to kernel taint^M
> > Trace:^M
> > [<fffffc0000b8c5b8>] napi_gro_receive+0x68/0x150^M
> > [<fffffc00009b409c>] receive_buf+0x50c/0x1b80^M
> > [<fffffc00009b58b8>] virtnet_poll+0x1a8/0x5b0^M
> > [<fffffc00009b58ec>] virtnet_poll+0x1dc/0x5b0^M
> > [<fffffc0000b8d17c>] __napi_poll+0x4c/0x270^M
> > [<fffffc0000b8d670>] net_rx_action+0x130/0x2c0^M
> > [<fffffc0000bd6cb0>] sch_direct_xmit+0x170/0x360^M
> > [<fffffc0000bd7000>] __qdisc_run+0x160/0x6c0^M
> > [<fffffc0000337b64>] do_softirq+0xa4/0xd0^M
> > [<fffffc0000337ca4>] __local_bh_enable_ip+0x114/0x120^M
> > [<fffffc0000b89554>] __dev_queue_xmit+0x484/0xa60^M
> > [<fffffc0000cd072c>] packet_sendmsg+0xe7c/0x1ba0^M
> > [<fffffc0000b53338>] __sys_sendto+0xf8/0x170^M
> > [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> > [<fffffc0000a9bf7c>] ehci_irq+0x2cc/0x5c0^M
> > [<fffffc0000a71334>] usb_hcd_irq+0x34/0x50^M
> > [<fffffc0000b521bc>] move_addr_to_kernel+0x3c/0x60^M
> > [<fffffc0000b532e4>] __sys_sendto+0xa4/0x170^M
> > [<fffffc0000b533d4>] sys_sendto+0x24/0x40^M
> > [<fffffc0000cfea38>] _raw_spin_lock+0x18/0x30^M
> > [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> > [<fffffc0000325298>] clipper_enable_irq+0x98/0x100^M
> > [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> > [<fffffc0000311514>] entSys+0xa4/0xc0^M
>
> OK, it would be nice if you could get line number from this stack trace.
>
Here you are:
napi_gro_receive (net/core/dev.c:6196)
receive_buf (drivers/net/virtio_net.c:1150)
virtnet_poll (drivers/net/virtio_net.c:1414 drivers/net/virtio_net.c:1519)
clipper_srm_device_interrupt (arch/alpha/kernel/sys_dp264.c:256)
virtnet_poll (drivers/net/virtio_net.c:1413 drivers/net/virtio_net.c:1519)
__napi_poll (net/core/dev.c:6962)
net_rx_action (net/core/dev.c:7029 net/core/dev.c:7116)
__qdisc_run (net/sched/sch_generic.c:376 net/sched/sch_generic.c:384)
do_softirq (./include/asm-generic/softirq_stack.h:10 kernel/softirq.c:460 kernel/softirq.c:447)
__local_bh_enable_ip (kernel/softirq.c:384)
__dev_queue_xmit (./include/linux/bottom_half.h:32 ./include/linux/rcupdate.h:746 net/core/dev.c:4272)
packet_sendmsg (net/packet/af_packet.c:3009 net/packet/af_packet.c:3034)
__sys_sendto (net/socket.c:654 net/socket.c:674 net/socket.c:1977)
__d_alloc (fs/dcache.c:1744)
packet_create (net/packet/af_packet.c:1192 net/packet/af_packet.c:3296)
move_addr_to_kernel (./include/linux/uaccess.h:192 net/socket.c:198 net/socket.c:192)
__sys_sendto (net/socket.c:1968)
sys_sendto (net/socket.c:1989 net/socket.c:1985)
sys_bind (net/socket.c:1648 net/socket.c:1646)
entSys (arch/alpha/kernel/entry.S:477)
Guenter
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
2021-04-20 15:42 ` Guenter Roeck
(?)
@ 2021-04-20 16:31 ` Eric Dumazet
2021-04-20 17:51 ` Guenter Roeck
-1 siblings, 1 reply; 17+ messages in thread
From: Eric Dumazet @ 2021-04-20 16:31 UTC (permalink / raw)
To: Guenter Roeck
Cc: Eric Dumazet, David S . Miller, Jakub Kicinski, netdev, syzbot,
Mat Martineau, Xuan Zhuo, Jason Wang, Michael S. Tsirkin,
virtualization
On Tue, Apr 20, 2021 at 5:42 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Tue, Apr 20, 2021 at 04:00:07PM +0200, Eric Dumazet wrote:
> > On Tue, Apr 20, 2021 at 3:48 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > On 4/20/21 2:43 AM, Eric Dumazet wrote:
> >
> > > >
> > >
> > > Unfortunately that doesn't fix the problem for me. With this patch applied
> > > on top of next-20210419, I still get the same crash as before:
> > >
> > > udhcpc: sending discover^M
> > > Unable to handle kernel paging request at virtual address 0000000000000004^M
> > > udhcpc(169): Oops -1^M
> > > pc = [<0000000000000004>] ra = [<fffffc0000b8c5b8>] ps = 0000 Not tainted^M
> > > pc is at 0x4^M
> > > ra is at napi_gro_receive+0x68/0x150^M
> > > v0 = 0000000000000000 t0 = 0000000000000008 t1 = 0000000000000000^M
> > > t2 = 0000000000000000 t3 = 000000000000000e t4 = 0000000000000038^M
> > > t5 = 000000000000ffff t6 = fffffc00002f298a t7 = fffffc0002c78000^M
> > > s0 = fffffc00010b3ca0 s1 = 0000000000000000 s2 = fffffc00011267e0^M
> > > s3 = 0000000000000000 s4 = fffffc00025f2008 s5 = fffffc00002f2940^M
> > > s6 = fffffc00025f2040^M
> > > a0 = fffffc00025f2008 a1 = fffffc00002f2940 a2 = fffffc0002ca000c^M
> > > a3 = fffffc00000250d0 a4 = 0000000effff0008 a5 = 0000000000000000^M
> > > t8 = fffffc00010b3c80 t9 = fffffc0002ca04cc t10= 0000000000000000^M
> > > t11= 00000000000004c0 pv = fffffc0000b8bc40 at = 0000000000000000^M
> > > gp = fffffc00010f9fb8 sp = 00000000df74db09^M
> > > Disabling lock debugging due to kernel taint^M
> > > Trace:^M
> > > [<fffffc0000b8c5b8>] napi_gro_receive+0x68/0x150^M
> > > [<fffffc00009b409c>] receive_buf+0x50c/0x1b80^M
> > > [<fffffc00009b58b8>] virtnet_poll+0x1a8/0x5b0^M
> > > [<fffffc00009b58ec>] virtnet_poll+0x1dc/0x5b0^M
> > > [<fffffc0000b8d17c>] __napi_poll+0x4c/0x270^M
> > > [<fffffc0000b8d670>] net_rx_action+0x130/0x2c0^M
> > > [<fffffc0000bd6cb0>] sch_direct_xmit+0x170/0x360^M
> > > [<fffffc0000bd7000>] __qdisc_run+0x160/0x6c0^M
> > > [<fffffc0000337b64>] do_softirq+0xa4/0xd0^M
> > > [<fffffc0000337ca4>] __local_bh_enable_ip+0x114/0x120^M
> > > [<fffffc0000b89554>] __dev_queue_xmit+0x484/0xa60^M
> > > [<fffffc0000cd072c>] packet_sendmsg+0xe7c/0x1ba0^M
> > > [<fffffc0000b53338>] __sys_sendto+0xf8/0x170^M
> > > [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> > > [<fffffc0000a9bf7c>] ehci_irq+0x2cc/0x5c0^M
> > > [<fffffc0000a71334>] usb_hcd_irq+0x34/0x50^M
> > > [<fffffc0000b521bc>] move_addr_to_kernel+0x3c/0x60^M
> > > [<fffffc0000b532e4>] __sys_sendto+0xa4/0x170^M
> > > [<fffffc0000b533d4>] sys_sendto+0x24/0x40^M
> > > [<fffffc0000cfea38>] _raw_spin_lock+0x18/0x30^M
> > > [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> > > [<fffffc0000325298>] clipper_enable_irq+0x98/0x100^M
> > > [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> > > [<fffffc0000311514>] entSys+0xa4/0xc0^M
> >
> > OK, it would be nice if you could get line number from this stack trace.
> >
>
> Here you are:
>
> napi_gro_receive (net/core/dev.c:6196)
> receive_buf (drivers/net/virtio_net.c:1150)
> virtnet_poll (drivers/net/virtio_net.c:1414 drivers/net/virtio_net.c:1519)
> clipper_srm_device_interrupt (arch/alpha/kernel/sys_dp264.c:256)
> virtnet_poll (drivers/net/virtio_net.c:1413 drivers/net/virtio_net.c:1519)
> __napi_poll (net/core/dev.c:6962)
> net_rx_action (net/core/dev.c:7029 net/core/dev.c:7116)
> __qdisc_run (net/sched/sch_generic.c:376 net/sched/sch_generic.c:384)
> do_softirq (./include/asm-generic/softirq_stack.h:10 kernel/softirq.c:460 kernel/softirq.c:447)
> __local_bh_enable_ip (kernel/softirq.c:384)
> __dev_queue_xmit (./include/linux/bottom_half.h:32 ./include/linux/rcupdate.h:746 net/core/dev.c:4272)
> packet_sendmsg (net/packet/af_packet.c:3009 net/packet/af_packet.c:3034)
> __sys_sendto (net/socket.c:654 net/socket.c:674 net/socket.c:1977)
> __d_alloc (fs/dcache.c:1744)
> packet_create (net/packet/af_packet.c:1192 net/packet/af_packet.c:3296)
> move_addr_to_kernel (./include/linux/uaccess.h:192 net/socket.c:198 net/socket.c:192)
> __sys_sendto (net/socket.c:1968)
> sys_sendto (net/socket.c:1989 net/socket.c:1985)
> sys_bind (net/socket.c:1648 net/socket.c:1646)
> entSys (arch/alpha/kernel/entry.S:477)
>
> Guenter
OK, I guess we are back to unaligned access, right ?
I guess sh arch should have failed as well ?
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 8cd76037c72481200ea3e8429e9fdfec005dad85..0579914d3dd84c24982c1ff85314cc7b8d0f8d2d
100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -415,7 +415,8 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
shinfo_size = SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
- if (len > GOOD_COPY_LEN && tailroom >= shinfo_size) {
+ if (len > GOOD_COPY_LEN && tailroom >= shinfo_size &&
+ (!NET_IP_ALIGN || ((unsigned long)p & 3) == 2)) {
skb = build_skb(p, truesize);
if (unlikely(!skb))
return NULL;
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
2021-04-20 16:31 ` Eric Dumazet
@ 2021-04-20 17:51 ` Guenter Roeck
0 siblings, 0 replies; 17+ messages in thread
From: Guenter Roeck @ 2021-04-20 17:51 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, David S . Miller, Jakub Kicinski, netdev, syzbot,
Mat Martineau, Xuan Zhuo, Jason Wang, Michael S. Tsirkin,
virtualization
On 4/20/21 9:31 AM, Eric Dumazet wrote:
> On Tue, Apr 20, 2021 at 5:42 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On Tue, Apr 20, 2021 at 04:00:07PM +0200, Eric Dumazet wrote:
>>> On Tue, Apr 20, 2021 at 3:48 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>>
>>>> On 4/20/21 2:43 AM, Eric Dumazet wrote:
>>>
>>>>>
>>>>
>>>> Unfortunately that doesn't fix the problem for me. With this patch applied
>>>> on top of next-20210419, I still get the same crash as before:
>>>>
>>>> udhcpc: sending discover^M
>>>> Unable to handle kernel paging request at virtual address 0000000000000004^M
>>>> udhcpc(169): Oops -1^M
>>>> pc = [<0000000000000004>] ra = [<fffffc0000b8c5b8>] ps = 0000 Not tainted^M
>>>> pc is at 0x4^M
>>>> ra is at napi_gro_receive+0x68/0x150^M
>>>> v0 = 0000000000000000 t0 = 0000000000000008 t1 = 0000000000000000^M
>>>> t2 = 0000000000000000 t3 = 000000000000000e t4 = 0000000000000038^M
>>>> t5 = 000000000000ffff t6 = fffffc00002f298a t7 = fffffc0002c78000^M
>>>> s0 = fffffc00010b3ca0 s1 = 0000000000000000 s2 = fffffc00011267e0^M
>>>> s3 = 0000000000000000 s4 = fffffc00025f2008 s5 = fffffc00002f2940^M
>>>> s6 = fffffc00025f2040^M
>>>> a0 = fffffc00025f2008 a1 = fffffc00002f2940 a2 = fffffc0002ca000c^M
>>>> a3 = fffffc00000250d0 a4 = 0000000effff0008 a5 = 0000000000000000^M
>>>> t8 = fffffc00010b3c80 t9 = fffffc0002ca04cc t10= 0000000000000000^M
>>>> t11= 00000000000004c0 pv = fffffc0000b8bc40 at = 0000000000000000^M
>>>> gp = fffffc00010f9fb8 sp = 00000000df74db09^M
>>>> Disabling lock debugging due to kernel taint^M
>>>> Trace:^M
>>>> [<fffffc0000b8c5b8>] napi_gro_receive+0x68/0x150^M
>>>> [<fffffc00009b409c>] receive_buf+0x50c/0x1b80^M
>>>> [<fffffc00009b58b8>] virtnet_poll+0x1a8/0x5b0^M
>>>> [<fffffc00009b58ec>] virtnet_poll+0x1dc/0x5b0^M
>>>> [<fffffc0000b8d17c>] __napi_poll+0x4c/0x270^M
>>>> [<fffffc0000b8d670>] net_rx_action+0x130/0x2c0^M
>>>> [<fffffc0000bd6cb0>] sch_direct_xmit+0x170/0x360^M
>>>> [<fffffc0000bd7000>] __qdisc_run+0x160/0x6c0^M
>>>> [<fffffc0000337b64>] do_softirq+0xa4/0xd0^M
>>>> [<fffffc0000337ca4>] __local_bh_enable_ip+0x114/0x120^M
>>>> [<fffffc0000b89554>] __dev_queue_xmit+0x484/0xa60^M
>>>> [<fffffc0000cd072c>] packet_sendmsg+0xe7c/0x1ba0^M
>>>> [<fffffc0000b53338>] __sys_sendto+0xf8/0x170^M
>>>> [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
>>>> [<fffffc0000a9bf7c>] ehci_irq+0x2cc/0x5c0^M
>>>> [<fffffc0000a71334>] usb_hcd_irq+0x34/0x50^M
>>>> [<fffffc0000b521bc>] move_addr_to_kernel+0x3c/0x60^M
>>>> [<fffffc0000b532e4>] __sys_sendto+0xa4/0x170^M
>>>> [<fffffc0000b533d4>] sys_sendto+0x24/0x40^M
>>>> [<fffffc0000cfea38>] _raw_spin_lock+0x18/0x30^M
>>>> [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
>>>> [<fffffc0000325298>] clipper_enable_irq+0x98/0x100^M
>>>> [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
>>>> [<fffffc0000311514>] entSys+0xa4/0xc0^M
>>>
>>> OK, it would be nice if you could get line number from this stack trace.
>>>
>>
>> Here you are:
>>
>> napi_gro_receive (net/core/dev.c:6196)
>> receive_buf (drivers/net/virtio_net.c:1150)
>> virtnet_poll (drivers/net/virtio_net.c:1414 drivers/net/virtio_net.c:1519)
>> clipper_srm_device_interrupt (arch/alpha/kernel/sys_dp264.c:256)
>> virtnet_poll (drivers/net/virtio_net.c:1413 drivers/net/virtio_net.c:1519)
>> __napi_poll (net/core/dev.c:6962)
>> net_rx_action (net/core/dev.c:7029 net/core/dev.c:7116)
>> __qdisc_run (net/sched/sch_generic.c:376 net/sched/sch_generic.c:384)
>> do_softirq (./include/asm-generic/softirq_stack.h:10 kernel/softirq.c:460 kernel/softirq.c:447)
>> __local_bh_enable_ip (kernel/softirq.c:384)
>> __dev_queue_xmit (./include/linux/bottom_half.h:32 ./include/linux/rcupdate.h:746 net/core/dev.c:4272)
>> packet_sendmsg (net/packet/af_packet.c:3009 net/packet/af_packet.c:3034)
>> __sys_sendto (net/socket.c:654 net/socket.c:674 net/socket.c:1977)
>> __d_alloc (fs/dcache.c:1744)
>> packet_create (net/packet/af_packet.c:1192 net/packet/af_packet.c:3296)
>> move_addr_to_kernel (./include/linux/uaccess.h:192 net/socket.c:198 net/socket.c:192)
>> __sys_sendto (net/socket.c:1968)
>> sys_sendto (net/socket.c:1989 net/socket.c:1985)
>> sys_bind (net/socket.c:1648 net/socket.c:1646)
>> entSys (arch/alpha/kernel/entry.S:477)
>>
>> Guenter
>
> OK, I guess we are back to unaligned access, right ?
> I guess sh arch should have failed as well ?
>
sh does indeed fail, with the same symptoms as before, but so far I was not
able to track it down to a specific commit. The alpha failure is different,
though. It is a NULL pointer access.
Anyway, testing ...
The patch below does indeed fix the problem I am seeing on sh.
... and it does fix the alpha problem as well. Neat, though I don't really understand
what a NULL pointer access and an unaligned access have to do with each other.
Great catch, thanks!
Guenter
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 8cd76037c72481200ea3e8429e9fdfec005dad85..0579914d3dd84c24982c1ff85314cc7b8d0f8d2d
> 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -415,7 +415,8 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
>
> shinfo_size = SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>
> - if (len > GOOD_COPY_LEN && tailroom >= shinfo_size) {
> + if (len > GOOD_COPY_LEN && tailroom >= shinfo_size &&
> + (!NET_IP_ALIGN || ((unsigned long)p & 3) == 2)) {
> skb = build_skb(p, truesize);
> if (unlikely(!skb))
> return NULL;
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
@ 2021-04-20 17:51 ` Guenter Roeck
0 siblings, 0 replies; 17+ messages in thread
From: Guenter Roeck @ 2021-04-20 17:51 UTC (permalink / raw)
To: Eric Dumazet
Cc: Xuan Zhuo, Eric Dumazet, Michael S. Tsirkin, netdev,
Mat Martineau, virtualization, syzbot, Jakub Kicinski,
David S . Miller
On 4/20/21 9:31 AM, Eric Dumazet wrote:
> On Tue, Apr 20, 2021 at 5:42 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On Tue, Apr 20, 2021 at 04:00:07PM +0200, Eric Dumazet wrote:
>>> On Tue, Apr 20, 2021 at 3:48 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>>
>>>> On 4/20/21 2:43 AM, Eric Dumazet wrote:
>>>
>>>>>
>>>>
>>>> Unfortunately that doesn't fix the problem for me. With this patch applied
>>>> on top of next-20210419, I still get the same crash as before:
>>>>
>>>> udhcpc: sending discover^M
>>>> Unable to handle kernel paging request at virtual address 0000000000000004^M
>>>> udhcpc(169): Oops -1^M
>>>> pc = [<0000000000000004>] ra = [<fffffc0000b8c5b8>] ps = 0000 Not tainted^M
>>>> pc is at 0x4^M
>>>> ra is at napi_gro_receive+0x68/0x150^M
>>>> v0 = 0000000000000000 t0 = 0000000000000008 t1 = 0000000000000000^M
>>>> t2 = 0000000000000000 t3 = 000000000000000e t4 = 0000000000000038^M
>>>> t5 = 000000000000ffff t6 = fffffc00002f298a t7 = fffffc0002c78000^M
>>>> s0 = fffffc00010b3ca0 s1 = 0000000000000000 s2 = fffffc00011267e0^M
>>>> s3 = 0000000000000000 s4 = fffffc00025f2008 s5 = fffffc00002f2940^M
>>>> s6 = fffffc00025f2040^M
>>>> a0 = fffffc00025f2008 a1 = fffffc00002f2940 a2 = fffffc0002ca000c^M
>>>> a3 = fffffc00000250d0 a4 = 0000000effff0008 a5 = 0000000000000000^M
>>>> t8 = fffffc00010b3c80 t9 = fffffc0002ca04cc t10= 0000000000000000^M
>>>> t11= 00000000000004c0 pv = fffffc0000b8bc40 at = 0000000000000000^M
>>>> gp = fffffc00010f9fb8 sp = 00000000df74db09^M
>>>> Disabling lock debugging due to kernel taint^M
>>>> Trace:^M
>>>> [<fffffc0000b8c5b8>] napi_gro_receive+0x68/0x150^M
>>>> [<fffffc00009b409c>] receive_buf+0x50c/0x1b80^M
>>>> [<fffffc00009b58b8>] virtnet_poll+0x1a8/0x5b0^M
>>>> [<fffffc00009b58ec>] virtnet_poll+0x1dc/0x5b0^M
>>>> [<fffffc0000b8d17c>] __napi_poll+0x4c/0x270^M
>>>> [<fffffc0000b8d670>] net_rx_action+0x130/0x2c0^M
>>>> [<fffffc0000bd6cb0>] sch_direct_xmit+0x170/0x360^M
>>>> [<fffffc0000bd7000>] __qdisc_run+0x160/0x6c0^M
>>>> [<fffffc0000337b64>] do_softirq+0xa4/0xd0^M
>>>> [<fffffc0000337ca4>] __local_bh_enable_ip+0x114/0x120^M
>>>> [<fffffc0000b89554>] __dev_queue_xmit+0x484/0xa60^M
>>>> [<fffffc0000cd072c>] packet_sendmsg+0xe7c/0x1ba0^M
>>>> [<fffffc0000b53338>] __sys_sendto+0xf8/0x170^M
>>>> [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
>>>> [<fffffc0000a9bf7c>] ehci_irq+0x2cc/0x5c0^M
>>>> [<fffffc0000a71334>] usb_hcd_irq+0x34/0x50^M
>>>> [<fffffc0000b521bc>] move_addr_to_kernel+0x3c/0x60^M
>>>> [<fffffc0000b532e4>] __sys_sendto+0xa4/0x170^M
>>>> [<fffffc0000b533d4>] sys_sendto+0x24/0x40^M
>>>> [<fffffc0000cfea38>] _raw_spin_lock+0x18/0x30^M
>>>> [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
>>>> [<fffffc0000325298>] clipper_enable_irq+0x98/0x100^M
>>>> [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
>>>> [<fffffc0000311514>] entSys+0xa4/0xc0^M
>>>
>>> OK, it would be nice if you could get line number from this stack trace.
>>>
>>
>> Here you are:
>>
>> napi_gro_receive (net/core/dev.c:6196)
>> receive_buf (drivers/net/virtio_net.c:1150)
>> virtnet_poll (drivers/net/virtio_net.c:1414 drivers/net/virtio_net.c:1519)
>> clipper_srm_device_interrupt (arch/alpha/kernel/sys_dp264.c:256)
>> virtnet_poll (drivers/net/virtio_net.c:1413 drivers/net/virtio_net.c:1519)
>> __napi_poll (net/core/dev.c:6962)
>> net_rx_action (net/core/dev.c:7029 net/core/dev.c:7116)
>> __qdisc_run (net/sched/sch_generic.c:376 net/sched/sch_generic.c:384)
>> do_softirq (./include/asm-generic/softirq_stack.h:10 kernel/softirq.c:460 kernel/softirq.c:447)
>> __local_bh_enable_ip (kernel/softirq.c:384)
>> __dev_queue_xmit (./include/linux/bottom_half.h:32 ./include/linux/rcupdate.h:746 net/core/dev.c:4272)
>> packet_sendmsg (net/packet/af_packet.c:3009 net/packet/af_packet.c:3034)
>> __sys_sendto (net/socket.c:654 net/socket.c:674 net/socket.c:1977)
>> __d_alloc (fs/dcache.c:1744)
>> packet_create (net/packet/af_packet.c:1192 net/packet/af_packet.c:3296)
>> move_addr_to_kernel (./include/linux/uaccess.h:192 net/socket.c:198 net/socket.c:192)
>> __sys_sendto (net/socket.c:1968)
>> sys_sendto (net/socket.c:1989 net/socket.c:1985)
>> sys_bind (net/socket.c:1648 net/socket.c:1646)
>> entSys (arch/alpha/kernel/entry.S:477)
>>
>> Guenter
>
> OK, I guess we are back to unaligned access, right ?
> I guess sh arch should have failed as well ?
>
sh does indeed fail, with the same symptoms as before, but so far I was not
able to track it down to a specific commit. The alpha failure is different,
though. It is a NULL pointer access.
Anyway, testing ...
The patch below does indeed fix the problem I am seeing on sh.
... and it does fix the alpha problem as well. Neat, though I don't really understand
what a NULL pointer access and an unaligned access have to do with each other.
Great catch, thanks!
Guenter
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 8cd76037c72481200ea3e8429e9fdfec005dad85..0579914d3dd84c24982c1ff85314cc7b8d0f8d2d
> 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -415,7 +415,8 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
>
> shinfo_size = SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>
> - if (len > GOOD_COPY_LEN && tailroom >= shinfo_size) {
> + if (len > GOOD_COPY_LEN && tailroom >= shinfo_size &&
> + (!NET_IP_ALIGN || ((unsigned long)p & 3) == 2)) {
> skb = build_skb(p, truesize);
> if (unlikely(!skb))
> return NULL;
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
2021-04-20 17:51 ` Guenter Roeck
(?)
@ 2021-04-20 17:52 ` Eric Dumazet
-1 siblings, 0 replies; 17+ messages in thread
From: Eric Dumazet @ 2021-04-20 17:52 UTC (permalink / raw)
To: Guenter Roeck
Cc: Eric Dumazet, David S . Miller, Jakub Kicinski, netdev, syzbot,
Mat Martineau, Xuan Zhuo, Jason Wang, Michael S. Tsirkin,
virtualization
On Tue, Apr 20, 2021 at 7:51 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 4/20/21 9:31 AM, Eric Dumazet wrote:
> > On Tue, Apr 20, 2021 at 5:42 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>
> >> On Tue, Apr 20, 2021 at 04:00:07PM +0200, Eric Dumazet wrote:
> >>> On Tue, Apr 20, 2021 at 3:48 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>
> >>>> On 4/20/21 2:43 AM, Eric Dumazet wrote:
> >>>
> >>>>>
> >>>>
> >>>> Unfortunately that doesn't fix the problem for me. With this patch applied
> >>>> on top of next-20210419, I still get the same crash as before:
> >>>>
> >>>> udhcpc: sending discover^M
> >>>> Unable to handle kernel paging request at virtual address 0000000000000004^M
> >>>> udhcpc(169): Oops -1^M
> >>>> pc = [<0000000000000004>] ra = [<fffffc0000b8c5b8>] ps = 0000 Not tainted^M
> >>>> pc is at 0x4^M
> >>>> ra is at napi_gro_receive+0x68/0x150^M
> >>>> v0 = 0000000000000000 t0 = 0000000000000008 t1 = 0000000000000000^M
> >>>> t2 = 0000000000000000 t3 = 000000000000000e t4 = 0000000000000038^M
> >>>> t5 = 000000000000ffff t6 = fffffc00002f298a t7 = fffffc0002c78000^M
> >>>> s0 = fffffc00010b3ca0 s1 = 0000000000000000 s2 = fffffc00011267e0^M
> >>>> s3 = 0000000000000000 s4 = fffffc00025f2008 s5 = fffffc00002f2940^M
> >>>> s6 = fffffc00025f2040^M
> >>>> a0 = fffffc00025f2008 a1 = fffffc00002f2940 a2 = fffffc0002ca000c^M
> >>>> a3 = fffffc00000250d0 a4 = 0000000effff0008 a5 = 0000000000000000^M
> >>>> t8 = fffffc00010b3c80 t9 = fffffc0002ca04cc t10= 0000000000000000^M
> >>>> t11= 00000000000004c0 pv = fffffc0000b8bc40 at = 0000000000000000^M
> >>>> gp = fffffc00010f9fb8 sp = 00000000df74db09^M
> >>>> Disabling lock debugging due to kernel taint^M
> >>>> Trace:^M
> >>>> [<fffffc0000b8c5b8>] napi_gro_receive+0x68/0x150^M
> >>>> [<fffffc00009b409c>] receive_buf+0x50c/0x1b80^M
> >>>> [<fffffc00009b58b8>] virtnet_poll+0x1a8/0x5b0^M
> >>>> [<fffffc00009b58ec>] virtnet_poll+0x1dc/0x5b0^M
> >>>> [<fffffc0000b8d17c>] __napi_poll+0x4c/0x270^M
> >>>> [<fffffc0000b8d670>] net_rx_action+0x130/0x2c0^M
> >>>> [<fffffc0000bd6cb0>] sch_direct_xmit+0x170/0x360^M
> >>>> [<fffffc0000bd7000>] __qdisc_run+0x160/0x6c0^M
> >>>> [<fffffc0000337b64>] do_softirq+0xa4/0xd0^M
> >>>> [<fffffc0000337ca4>] __local_bh_enable_ip+0x114/0x120^M
> >>>> [<fffffc0000b89554>] __dev_queue_xmit+0x484/0xa60^M
> >>>> [<fffffc0000cd072c>] packet_sendmsg+0xe7c/0x1ba0^M
> >>>> [<fffffc0000b53338>] __sys_sendto+0xf8/0x170^M
> >>>> [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> >>>> [<fffffc0000a9bf7c>] ehci_irq+0x2cc/0x5c0^M
> >>>> [<fffffc0000a71334>] usb_hcd_irq+0x34/0x50^M
> >>>> [<fffffc0000b521bc>] move_addr_to_kernel+0x3c/0x60^M
> >>>> [<fffffc0000b532e4>] __sys_sendto+0xa4/0x170^M
> >>>> [<fffffc0000b533d4>] sys_sendto+0x24/0x40^M
> >>>> [<fffffc0000cfea38>] _raw_spin_lock+0x18/0x30^M
> >>>> [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> >>>> [<fffffc0000325298>] clipper_enable_irq+0x98/0x100^M
> >>>> [<fffffc0000cfec18>] _raw_spin_unlock+0x18/0x30^M
> >>>> [<fffffc0000311514>] entSys+0xa4/0xc0^M
> >>>
> >>> OK, it would be nice if you could get line number from this stack trace.
> >>>
> >>
> >> Here you are:
> >>
> >> napi_gro_receive (net/core/dev.c:6196)
> >> receive_buf (drivers/net/virtio_net.c:1150)
> >> virtnet_poll (drivers/net/virtio_net.c:1414 drivers/net/virtio_net.c:1519)
> >> clipper_srm_device_interrupt (arch/alpha/kernel/sys_dp264.c:256)
> >> virtnet_poll (drivers/net/virtio_net.c:1413 drivers/net/virtio_net.c:1519)
> >> __napi_poll (net/core/dev.c:6962)
> >> net_rx_action (net/core/dev.c:7029 net/core/dev.c:7116)
> >> __qdisc_run (net/sched/sch_generic.c:376 net/sched/sch_generic.c:384)
> >> do_softirq (./include/asm-generic/softirq_stack.h:10 kernel/softirq.c:460 kernel/softirq.c:447)
> >> __local_bh_enable_ip (kernel/softirq.c:384)
> >> __dev_queue_xmit (./include/linux/bottom_half.h:32 ./include/linux/rcupdate.h:746 net/core/dev.c:4272)
> >> packet_sendmsg (net/packet/af_packet.c:3009 net/packet/af_packet.c:3034)
> >> __sys_sendto (net/socket.c:654 net/socket.c:674 net/socket.c:1977)
> >> __d_alloc (fs/dcache.c:1744)
> >> packet_create (net/packet/af_packet.c:1192 net/packet/af_packet.c:3296)
> >> move_addr_to_kernel (./include/linux/uaccess.h:192 net/socket.c:198 net/socket.c:192)
> >> __sys_sendto (net/socket.c:1968)
> >> sys_sendto (net/socket.c:1989 net/socket.c:1985)
> >> sys_bind (net/socket.c:1648 net/socket.c:1646)
> >> entSys (arch/alpha/kernel/entry.S:477)
> >>
> >> Guenter
> >
> > OK, I guess we are back to unaligned access, right ?
> > I guess sh arch should have failed as well ?
> >
>
> sh does indeed fail, with the same symptoms as before, but so far I was not
> able to track it down to a specific commit. The alpha failure is different,
> though. It is a NULL pointer access.
Not sure alpha linux kernel deals nicely with unaligned trap ?
>
> Anyway, testing ...
>
> The patch below does indeed fix the problem I am seeing on sh.
>
> ... and it does fix the alpha problem as well. Neat, though I don't really understand
> what a NULL pointer access and an unaligned access have to do with each other.
>
> Great catch, thanks!
>
> Guenter
>
>
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 8cd76037c72481200ea3e8429e9fdfec005dad85..0579914d3dd84c24982c1ff85314cc7b8d0f8d2d
> > 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -415,7 +415,8 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> >
> > shinfo_size = SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> >
> > - if (len > GOOD_COPY_LEN && tailroom >= shinfo_size) {
> > + if (len > GOOD_COPY_LEN && tailroom >= shinfo_size &&
> > + (!NET_IP_ALIGN || ((unsigned long)p & 3) == 2)) {
> > skb = build_skb(p, truesize);
> > if (unlikely(!skb))
> > return NULL;
> >
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
2021-04-20 17:51 ` Guenter Roeck
@ 2021-04-20 18:11 ` Eric Dumazet
-1 siblings, 0 replies; 17+ messages in thread
From: Eric Dumazet @ 2021-04-20 18:11 UTC (permalink / raw)
To: Guenter Roeck, Eric Dumazet
Cc: Eric Dumazet, David S . Miller, Jakub Kicinski, netdev, syzbot,
Mat Martineau, Xuan Zhuo, Jason Wang, Michael S. Tsirkin,
virtualization
On 4/20/21 7:51 PM, Guenter Roeck wrote:
>
> sh does indeed fail, with the same symptoms as before, but so far I was not
> able to track it down to a specific commit. The alpha failure is different,
> though. It is a NULL pointer access.
>
> Anyway, testing ...
>
> The patch below does indeed fix the problem I am seeing on sh.
>
> ... and it does fix the alpha problem as well. Neat, though I don't really understand
> what a NULL pointer access and an unaligned access have to do with each other.
>
> Great catch, thanks!
>
> Guenter
>
Note that build_skb(), without an additional skb_reserve(skb, NET_IP_ALIGN)
can not possibly work on arches that care about alignments.
That is because we can not both align skb->data and skb_shinfo(skb)
So unless we change build_skb() to make sure to align skb_shinfo(),
a fix could be simply :
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 8cd76037c72481200ea3e8429e9fdfec005dad85..9cbe9c1737649450e451e3c65f59f794d1bf34b0 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -415,7 +415,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
shinfo_size = SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
- if (len > GOOD_COPY_LEN && tailroom >= shinfo_size) {
+ if (!_NET_IP_ALIGN && len > GOOD_COPY_LEN && tailroom >= shinfo_size) {
skb = build_skb(p, truesize);
if (unlikely(!skb))
return NULL;
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
@ 2021-04-20 18:11 ` Eric Dumazet
0 siblings, 0 replies; 17+ messages in thread
From: Eric Dumazet @ 2021-04-20 18:11 UTC (permalink / raw)
To: Guenter Roeck, Eric Dumazet
Cc: Xuan Zhuo, Eric Dumazet, Michael S. Tsirkin, netdev,
Mat Martineau, virtualization, syzbot, Jakub Kicinski,
David S . Miller
On 4/20/21 7:51 PM, Guenter Roeck wrote:
>
> sh does indeed fail, with the same symptoms as before, but so far I was not
> able to track it down to a specific commit. The alpha failure is different,
> though. It is a NULL pointer access.
>
> Anyway, testing ...
>
> The patch below does indeed fix the problem I am seeing on sh.
>
> ... and it does fix the alpha problem as well. Neat, though I don't really understand
> what a NULL pointer access and an unaligned access have to do with each other.
>
> Great catch, thanks!
>
> Guenter
>
Note that build_skb(), without an additional skb_reserve(skb, NET_IP_ALIGN)
can not possibly work on arches that care about alignments.
That is because we can not both align skb->data and skb_shinfo(skb)
So unless we change build_skb() to make sure to align skb_shinfo(),
a fix could be simply :
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 8cd76037c72481200ea3e8429e9fdfec005dad85..9cbe9c1737649450e451e3c65f59f794d1bf34b0 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -415,7 +415,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
shinfo_size = SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
- if (len > GOOD_COPY_LEN && tailroom >= shinfo_size) {
+ if (!_NET_IP_ALIGN && len > GOOD_COPY_LEN && tailroom >= shinfo_size) {
skb = build_skb(p, truesize);
if (unlikely(!skb))
return NULL;
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
2021-04-20 9:43 ` Eric Dumazet
@ 2021-04-21 2:15 ` Jason Wang
-1 siblings, 0 replies; 17+ messages in thread
From: Jason Wang @ 2021-04-21 2:15 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller, Jakub Kicinski
Cc: netdev, Eric Dumazet, syzbot, Guenter Roeck, Mat Martineau,
Xuan Zhuo, Michael S. Tsirkin, virtualization
在 2021/4/20 下午5:43, Eric Dumazet 写道:
> From: Eric Dumazet <edumazet@google.com>
>
> KASAN/syzbot had 4 reports, one of them being:
>
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]
> BUG: KASAN: slab-out-of-bounds in page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
> Read of size 12 at addr ffff888014a5f800 by task systemd-udevd/8445
>
> CPU: 0 PID: 8445 Comm: systemd-udevd Not tainted 5.12.0-rc8-next-20210419-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:233
> __kasan_report mm/kasan/report.c:419 [inline]
> kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:436
> check_region_inline mm/kasan/generic.c:180 [inline]
> kasan_check_range+0x13d/0x180 mm/kasan/generic.c:186
> memcpy+0x20/0x60 mm/kasan/shadow.c:65
> memcpy include/linux/fortify-string.h:191 [inline]
> page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
> receive_mergeable drivers/net/virtio_net.c:1009 [inline]
> receive_buf+0x2bc0/0x6250 drivers/net/virtio_net.c:1119
> virtnet_receive drivers/net/virtio_net.c:1411 [inline]
> virtnet_poll+0x568/0x10b0 drivers/net/virtio_net.c:1516
> __napi_poll+0xaf/0x440 net/core/dev.c:6962
> napi_poll net/core/dev.c:7029 [inline]
> net_rx_action+0x801/0xb40 net/core/dev.c:7116
> __do_softirq+0x29b/0x9fe kernel/softirq.c:559
> invoke_softirq kernel/softirq.c:433 [inline]
> __irq_exit_rcu+0x136/0x200 kernel/softirq.c:637
> irq_exit_rcu+0x5/0x20 kernel/softirq.c:649
> common_interrupt+0xa4/0xd0 arch/x86/kernel/irq.c:240
>
> Fixes: fb32856b16ad ("virtio-net: page_to_skb() use build_skb when there's sufficient tailroom")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Reported-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: virtualization@lists.linux-foundation.org
> ---
Acked-by: Jason Wang <jasowang@redhat.com>
> drivers/net/virtio_net.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 8cd76037c72481200ea3e8429e9fdfec005dad85..2e28c04aa6351d2b4016f7d277ce104c4970069d 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -385,6 +385,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> struct sk_buff *skb;
> struct virtio_net_hdr_mrg_rxbuf *hdr;
> unsigned int copy, hdr_len, hdr_padded_len;
> + struct page *page_to_free = NULL;
> int tailroom, shinfo_size;
> char *p, *hdr_p;
>
> @@ -445,7 +446,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> if (len)
> skb_add_rx_frag(skb, 0, page, offset, len, truesize);
> else
> - put_page(page);
> + page_to_free = page;
> goto ok;
> }
>
> @@ -479,6 +480,8 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> hdr = skb_vnet_hdr(skb);
> memcpy(hdr, hdr_p, hdr_len);
> }
> + if (page_to_free)
> + put_page(page_to_free);
>
> if (metasize) {
> __skb_pull(skb, metasize);
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH net-next] virtio-net: fix use-after-free in page_to_skb()
@ 2021-04-21 2:15 ` Jason Wang
0 siblings, 0 replies; 17+ messages in thread
From: Jason Wang @ 2021-04-21 2:15 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller, Jakub Kicinski
Cc: Xuan Zhuo, Michael S. Tsirkin, netdev, Mat Martineau,
virtualization, Eric Dumazet, syzbot, Guenter Roeck
在 2021/4/20 下午5:43, Eric Dumazet 写道:
> From: Eric Dumazet <edumazet@google.com>
>
> KASAN/syzbot had 4 reports, one of them being:
>
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]
> BUG: KASAN: slab-out-of-bounds in page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
> Read of size 12 at addr ffff888014a5f800 by task systemd-udevd/8445
>
> CPU: 0 PID: 8445 Comm: systemd-udevd Not tainted 5.12.0-rc8-next-20210419-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:233
> __kasan_report mm/kasan/report.c:419 [inline]
> kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:436
> check_region_inline mm/kasan/generic.c:180 [inline]
> kasan_check_range+0x13d/0x180 mm/kasan/generic.c:186
> memcpy+0x20/0x60 mm/kasan/shadow.c:65
> memcpy include/linux/fortify-string.h:191 [inline]
> page_to_skb+0x5cf/0xb70 drivers/net/virtio_net.c:480
> receive_mergeable drivers/net/virtio_net.c:1009 [inline]
> receive_buf+0x2bc0/0x6250 drivers/net/virtio_net.c:1119
> virtnet_receive drivers/net/virtio_net.c:1411 [inline]
> virtnet_poll+0x568/0x10b0 drivers/net/virtio_net.c:1516
> __napi_poll+0xaf/0x440 net/core/dev.c:6962
> napi_poll net/core/dev.c:7029 [inline]
> net_rx_action+0x801/0xb40 net/core/dev.c:7116
> __do_softirq+0x29b/0x9fe kernel/softirq.c:559
> invoke_softirq kernel/softirq.c:433 [inline]
> __irq_exit_rcu+0x136/0x200 kernel/softirq.c:637
> irq_exit_rcu+0x5/0x20 kernel/softirq.c:649
> common_interrupt+0xa4/0xd0 arch/x86/kernel/irq.c:240
>
> Fixes: fb32856b16ad ("virtio-net: page_to_skb() use build_skb when there's sufficient tailroom")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Reported-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: virtualization@lists.linux-foundation.org
> ---
Acked-by: Jason Wang <jasowang@redhat.com>
> drivers/net/virtio_net.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 8cd76037c72481200ea3e8429e9fdfec005dad85..2e28c04aa6351d2b4016f7d277ce104c4970069d 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -385,6 +385,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> struct sk_buff *skb;
> struct virtio_net_hdr_mrg_rxbuf *hdr;
> unsigned int copy, hdr_len, hdr_padded_len;
> + struct page *page_to_free = NULL;
> int tailroom, shinfo_size;
> char *p, *hdr_p;
>
> @@ -445,7 +446,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> if (len)
> skb_add_rx_frag(skb, 0, page, offset, len, truesize);
> else
> - put_page(page);
> + page_to_free = page;
> goto ok;
> }
>
> @@ -479,6 +480,8 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
> hdr = skb_vnet_hdr(skb);
> memcpy(hdr, hdr_p, hdr_len);
> }
> + if (page_to_free)
> + put_page(page_to_free);
>
> if (metasize) {
> __skb_pull(skb, metasize);
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 17+ messages in thread