linux-kernel - [RFC PATCH v1 0/3] fix header length on skb merging

lists.openwall.net		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]

Message-ID: <e141e6f1-00ae-232c-b840-b146bdb10e99@sberdevices.ru>
Date:   Sun, 19 Mar 2023 21:49:36 +0300
From:   Arseniy Krasnov <avkrasnov@...rdevices.ru>
To:     Stefan Hajnoczi <stefanha@...hat.com>,
        Stefano Garzarella <sgarzare@...hat.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Bobby Eshleman <bobby.eshleman@...edance.com>
CC:     <kvm@...r.kernel.org>, <virtualization@...ts.linux-foundation.org>,
        <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <kernel@...rdevices.ru>, <oxffffaa@...il.com>,
        <avkrasnov@...rdevices.ru>
Subject: [RFC PATCH v1 0/3] fix header length on skb merging

Hello,

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
above.

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
detect.

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(-)

-- 
2.25.1