netdev - Regressions with VMBus/VSCs hardening changes

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: <20210212165050.GA11906@anparri>
Date:   Fri, 12 Feb 2021 17:50:50 +0100
From:   Andrea Parri <parri.andrea@...il.com>
To:     linux-kernel@...r.kernel.org
Cc:     kys@...rosoft.com, haiyangz@...rosoft.com, sthemmin@...rosoft.com,
        wei.liu@...nel.org, mikelley@...rosoft.com, jejb@...ux.ibm.com,
        martin.petersen@...cle.com, davem@...emloft.net, kuba@...nel.org,
        linux-hyperv@...r.kernel.org, linux-scsi@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Regressions with VMBus/VSCs hardening changes

Hi all,

I'm reporting two regressions following certain VMBus/VSCs hardening changes
we've been discussing 'recently', unfortunately the first regression already
touched/affects mainline while the second one is in hyperv-next:

1) [mainline]

The first regression manifests with the following message (several):

  hv_vmbus: No request id available

I could reliably reproduce such message/behavior by running the command:

  fio --name=seqwrite --rw=read --direct=1 --ioengine=libaio --bs=32k --numjobs=4 --size=2G --runtime=60

(the message is triggered when files are being created).

I've bisected this regression to commit:

  453de21c2b8281 ("scsi: storvsc: Use vmbus_requestor to generate transaction IDs for VMBus hardening")

2) [hyperv-next]

The second regression manifests with various messages including:

  hv_netvsc 9c5f5000-0499-4b18-b2eb-a8d5c57c8774 eth0: Unknown nvsp packet type received 51966

  hv_netvsc 9c5f5000-0499-4b18-b2eb-a8d5c57c8774 eth0: unhandled packet type 0, tid 0

  hv_netvsc 9c5f5000-0499-4b18-b2eb-a8d5c57c8774 eth0: Incorrect transaction id

  hv_netvsc 9c5f5000-0499-4b18-b2eb-a8d5c57c8774 eth0: Invalid rndis_msg (buflen: 262, msg_len: 1728)

The connection was then typically lost/reset by the peer.

I could reproduce such behavior/messages by running the test:

  ntttcp -r -m 8,*,<receiver IP address> # receiver

  ntttcp -s -m 8,*,<receiver IP address> -ns -t 60 # sender

I bisected this regression to commit:

  a8c3209998afb5 ("Drivers: hv: vmbus: Copy packets sent by Hyper-V out of the ring buffer")

---
I am investigating but don't have fixes for these regressions now: given the
'timing' (-rc7 with the next merge window at the door...) I would propose to
revert/drop the interested changes:

1) 453de21c2b8281 is part of the so called 'vmbus_requestor' series that was
   applied during the merge window for 5.11:

  e8b7db38449ac5 ("Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus hardening")
  453de21c2b8281 ("scsi: storvsc: Use vmbus_requestor to generate transaction IDs for VMBus hardening")
  4d18fcc95f5095 ("hv_netvsc: Use vmbus_requestor to generate transaction IDs for VMBus hardening")

  I could prepare/submit patches to revert such commits (asap but likely not
  before tomorrow/late Saturday - EU time).

2) IIUC a8c3209998afb5 could be dropped (after rebase) without further modi-
   fications to hyperv-next.

Other suggestions/thoughts?

Thanks,
  Andrea