RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1939418 - Invalid hash calculated when using IPv6 RSS offload
Summary: Invalid hash calculated when using IPv6 RSS offload
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: qemu-kvm
Version: 8.4
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: ybendito
QA Contact: Quan Wenli
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-03-16 11:31 UTC by Philippe Mathieu-Daudé
Modified: 2021-12-07 22:58 UTC (History)
8 users (show)

Fixed In Version: qemu-kvm-6.0.0-22
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-11-09 18:00:11 UTC
Type: Bug
Target Upstream Version: 6.0
Embargoed:

Attachments (Terms of Use)
Suggested fix for eth.c (2.46 KB, application/mbox)
2021-03-21 05:56 UTC, ybendito 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2021:4191 0 None None None 2021-11-09 18:00:53 UTC

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
Note You need to log in before you can comment on or make changes to this bug.