Bug 1939418

Summary: Invalid hash calculated when using IPv6 RSS offload
Product: Red Hat Enterprise Linux 8 Reporter: Philippe Mathieu-Daudé <philmd>
Component: qemu-kvmAssignee: ybendito
qemu-kvm sub component: Networking QA Contact: Quan Wenli <wquan>
Status: CLOSED ERRATA Docs Contact:
Severity: low    
Priority: low CC: chayang, jasowang, mdean, sgarzare, virt-maint, ybendito, yfu, yvugenfi
Version: 8.4   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-6.0.0-22 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-11-09 18:00:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version: 6.0
Embargoed:
Attachments:
Description Flags
Suggested fix for eth.c none

Description Philippe Mathieu-Daudé 2021-03-16 11:31:14 UTC 
Description of problem: (edited)

Since its introduction in 2016, the procedure net/eth.c::_eth_get_rss_ex_dst_addr QEMU never worked correctly.
It is related to the case where the IPv6 packet contains extension "route type 2" header with the destination IPv6 address different from the destination IPv6 address in the IPv6 header.
In such case the RSS hash is not calculated correctly, the mentioned procedure accesses out of bounds stack locations.
This behavior is incorrect but should not cause any functional problem.


Additional info:

Upstream fix:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg790001.html
Comment 1 Quan Wenli 2021-03-17 02:51:26 UTC 
hello Philippe Mathieu-Daudé

Do we have reproducer for this bug?

Thanks, wenli
Comment 2 Philippe Mathieu-Daudé 2021-03-17 17:11:33 UTC 
(In reply to Quan Wenli from comment #1)
> 
> Do we have reproducer for this bug?

Forwarding this question to Yuri who know how to test.
Comment 3 ybendito 2021-03-21 05:56:27 UTC 
Created attachment 1764992 [details]
Suggested fix for eth.c
Comment 4 ybendito 2021-03-21 06:05:05 UTC 
In order to ensure the fix does the job I've used Windows HCK test procedure:
- Test 2c_Mini6RSSSendRecv test, implemented in HCK script 2c_Mini6RSSSendRecv.wsf, https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/6ce7b1b3-c5f2-4fe0-99f4-dbf55971411b
- slightly modified netkvm driver (must) to report the hash provided by the device (by default the driver calculates the hash and reports the calculated value issuing log message in case the device reported different hash)
- upstream qemu, pc, 4 cpus (1s x 2c x 2t) e1000 + virtio-net,4 queues, 9 vectors, vhost off, rss on, hash on
On clean upstream the test fails in 18 variations, the failure is "Miniport computed incorrect hash value for some net buffers" where the packet type is "IPv6 packets with route type 2 header and TCP header"
With the fix from Philippe (in the description) the test passes
I'd suggest simpler fix (comment #3), with it the test passes also
AFAIU The reproducer is an original issue mentioned in https://www.mail-archive.com/qemu-devel@nongnu.org/msg790003.html
Comment 5 ybendito 2021-04-05 06:43:09 UTC 
Fixed in upstream
https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg07367.html
Comment 8 Yanan Fu 2021-07-08 16:06:42 UTC 
Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass with 'qemu-kvm-6.0.0-22.module+el8.5.0+11695+95588379'.
Comment 9 Quan Wenli 2021-07-09 04:50:54 UTC 
> AFAIU The reproducer is an original issue mentioned in
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg790003.html

With the steps from above, there is no qemu crashed with qemu-kvm-6.0.0-22.module+el8.5.0+11695+95588379.x86_64. 

# cat << EOF | /usr/libexec/qemu-kvm -M pc-q35-rhel8.5.0 \
test -mo> -accel qtest -monitor none \
> -serial none -nographic -qtest stdio
> outl 0xcf8 0x80001010
> outl 0xcfc 0xe1020000
> outl 0xcf8 0x80001004
> outw 0xcfc 0x7
> write 0x25 0x1 0x86
> write 0x26 0x1 0xdd
> write 0x4f 0x1 0x2b
> write 0xe1020030 0x4 0x190002e1
> write 0xe102003a 0x2 0x0807
> write 0xe1020048 0x4 0x12077cdd
> write 0xe1020400 0x4 0xba077cdd
> write 0xe1020420 0x4 0x190002e1
> write 0xe1020428 0x4 0x3509d807
> write 0xe1020438 0x1 0xe2
> EOF
[I 1625806009.441137] OPENED
[R +0.013145] outl 0xcf8 0x80001010
[S +0.013162] OK
OK
[R +0.013168] outl 0xcfc 0xe1020000
[S +0.013175] OK
OK
[R +0.013179] outl 0xcf8 0x80001004
[S +0.013186] OK
OK
[R +0.013195] outw 0xcfc 0x7
[S +0.013316] OK
OK
[R +0.013324] write 0x25 0x1 0x86
[S +0.013885] OK
OK
[R +0.013890] write 0x26 0x1 0xdd
[S +0.013895] OK
OK
[R +0.013897] write 0x4f 0x1 0x2b
[S +0.013902] OK
OK
[R +0.013904] write 0xe1020030 0x4 0x190002e1
[S +0.013911] OK
OK
[R +0.013926] write 0xe102003a 0x2 0x0807
[S +0.013932] OK
OK
[R +0.013937] write 0xe1020048 0x4 0x12077cdd
[S +0.013946] OK
OK
[R +0.013949] write 0xe1020400 0x4 0xba077cdd
[S +0.013957] OK
OK
[R +0.013961] write 0xe1020420 0x4 0x190002e1
[S +0.013968] OK
OK
[R +0.013973] write 0xe1020428 0x4 0x3509d807
[S +0.013981] OK
OK
[R +0.013985] write 0xe1020438 0x1 0xe2
[S +0.014117] OK
OK
[I +0.014137] CLOSED

Base on above, this bug should be fixed. Thanks all
Comment 10 Quan Wenli 2021-07-09 04:58:24 UTC 
(In reply to Quan Wenli from comment #9)
> > AFAIU The reproducer is an original issue mentioned in
> > https://www.mail-archive.com/qemu-devel@nongnu.org/msg790003.html
> 
> With the steps from above, there is no qemu crashed with
> qemu-kvm-6.0.0-22.module+el8.5.0+11695+95588379.x86_64. 
> 
> # cat << EOF | /usr/libexec/qemu-kvm -M pc-q35-rhel8.5.0 \
> test -mo> -accel qtest -monitor none \
> > -serial none -nographic -qtest stdio
> > outl 0xcf8 0x80001010
> > outl 0xcfc 0xe1020000
> > outl 0xcf8 0x80001004
> > outw 0xcfc 0x7
> > write 0x25 0x1 0x86
> > write 0x26 0x1 0xdd
> > write 0x4f 0x1 0x2b
> > write 0xe1020030 0x4 0x190002e1
> > write 0xe102003a 0x2 0x0807
> > write 0xe1020048 0x4 0x12077cdd
> > write 0xe1020400 0x4 0xba077cdd
> > write 0xe1020420 0x4 0x190002e1
> > write 0xe1020428 0x4 0x3509d807
> > write 0xe1020438 0x1 0xe2
> > EOF
> [I 1625806009.441137] OPENED
> [R +0.013145] outl 0xcf8 0x80001010
> [S +0.013162] OK
> OK
> [R +0.013168] outl 0xcfc 0xe1020000
> [S +0.013175] OK
> OK
> [R +0.013179] outl 0xcf8 0x80001004
> [S +0.013186] OK
> OK
> [R +0.013195] outw 0xcfc 0x7
> [S +0.013316] OK
> OK
> [R +0.013324] write 0x25 0x1 0x86
> [S +0.013885] OK
> OK
> [R +0.013890] write 0x26 0x1 0xdd
> [S +0.013895] OK
> OK
> [R +0.013897] write 0x4f 0x1 0x2b
> [S +0.013902] OK
> OK
> [R +0.013904] write 0xe1020030 0x4 0x190002e1
> [S +0.013911] OK
> OK
> [R +0.013926] write 0xe102003a 0x2 0x0807
> [S +0.013932] OK
> OK
> [R +0.013937] write 0xe1020048 0x4 0x12077cdd
> [S +0.013946] OK
> OK
> [R +0.013949] write 0xe1020400 0x4 0xba077cdd
> [S +0.013957] OK
> OK
> [R +0.013961] write 0xe1020420 0x4 0x190002e1
> [S +0.013968] OK
> OK
> [R +0.013973] write 0xe1020428 0x4 0x3509d807
> [S +0.013981] OK
> OK
> [R +0.013985] write 0xe1020438 0x1 0xe2
> [S +0.014117] OK
> OK
> [I +0.014137] CLOSED
> 
> Base on above, this bug should be fixed. Thanks all

Base on above, set it to VERIFIED. and removed sanityonly
Comment 13 errata-xmlrpc 2021-11-09 18:00:11 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: virt:rhel and virt-devel:rhel security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:4191