| Message ID | 20210420094341.3259328-1-eric.dumazet@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net-next] virtio-net: fix use-after-free in page_to_skb() | expand |
| Context | Check | Description |
|---|---|---|
| netdev/cover_letter | success | Link |
| netdev/fixes_present | success | Link |
| netdev/patch_count | success | Link |
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/subject_prefix | success | Link |
| netdev/cc_maintainers | success | CCed 7 of 7 maintainers |
| netdev/source_inline | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Link |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/build_32bit | fail | Errors and warnings before: 6 this patch: 6 |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/verify_fixes | success | Link |
| netdev/checkpatch | warning | WARNING: Possible repeated word: 'Google' |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
| netdev/header_inline | success | Link |
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
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
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)
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
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;
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; >
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; > > >
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;
在 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);
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);