lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 19 Mar 2023 21:49:36 +0300
From:   Arseniy Krasnov <>
To:     Stefan Hajnoczi <>,
        Stefano Garzarella <>,
        "David S. Miller" <>,
        Eric Dumazet <>,
        Jakub Kicinski <>,
        Paolo Abeni <>,
        Bobby Eshleman <>
CC:     <>, <>,
        <>, <>,
        <>, <>,
Subject: [RFC PATCH v1 0/3] fix header length on skb merging


this patchset fixes skbuff merging during rx path. Problem fires when
we are trying to append data to skbuff which is processed in dequeue
callback at the same time. Dequeue callback calls 'skb_pull()' which
changes 'skb->len'. While appending data, this dynamic 'skb->len' will
be used to update length in header of last skbuff. This is wrong, because
length in header is used to update credit parameters ('rx_bytes' and
'fwd_cnt') and must be constant. To set valid length in header of last
skbuff after appending new data to it, we need to sum header values from
both last and new skbuff.

This bug was introduced by:
Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")

I really forgot about this branch in rx path when implemented patch

This patchset contains 3 patches:
1) Fix itself.
2) Patch with WARN() as kernel part of reproducer. I've added error
   return from dequeue callback if this bug fires, otherwise you'll
   get busyloop in kernel: callback always returns 0, but rx loop in
   af_vsock.c sees that rx_bytes is non-zero thus trying to call
   dequeue callback again and again.
3) Patch with reproducer in vsock_test.c. It looks like new test, but
   i'm not sure how to test this branch (appending data to last skbuff)
   of virtio transport. So only way to detect problem is WARN() in 2).

May be, it will be good practice to add some WARN() checks like in 2)
to different parts of virtio/vsock, because such bugs are difficult to

Arseniy Krasnov (3):
  virtio/vsock: fix header length on skb merging
  virtio/vsock: add WARN() for invalid state of socket
  test/vsock: skbuff merging test

 net/vmw_vsock/virtio_transport_common.c |  9 ++-
 tools/testing/vsock/vsock_test.c        | 81 +++++++++++++++++++++++++
 2 files changed, 89 insertions(+), 1 deletion(-)


Powered by blists - more mailing lists