Bug 1202665 - (CVE-2022-2962) VUL-0: CVE-2022-2962: qemu,kvm: QEMU: tulip: DMA reentrancy issue leads to stack or heap overflow
(CVE-2022-2962)
VUL-0: CVE-2022-2962: qemu,kvm: QEMU: tulip: DMA reentrancy issue leads to st...
Status: NEW
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Minor
: ---
Assigned To: Security Team bot
Security Team bot
https://smash.suse.de/issue/340537/
CVSSv3.1:SUSE:CVE-2022-2962:6.0:(AV:L...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2022-08-24 07:30 UTC by Hu
Modified: 2022-10-27 18:38 UTC (History)
4 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hu 2022-08-24 07:30:31 UTC
rh#2120631

When tulip reads or writes to the rx/tx descriptor or copies the rx/tx frame, it doesn't check whether the destination address is its own MMIO address. So crafted content can cause the device to trigger MMIO handlers again to modify some global variables and cause stack or heap overflow.

-- [ QEMU command line:

./qemu-system-x86_64 -machine type=q35,accel=qtest -nodefaults -device tulip -qtest stdio -nographic


-- [ POC:

outl 0xcf8 0x80000804             /* PCICMD—PCI Command Register */
outl 0xcfc 0x107                  /* Enables accesses*/
outl 0xcf8 0x80000814             /* Memory Bar 1*/
outl 0xcfc 0xfebf1000             /* Set MMIO Address to 0xfebf1000*/
writel 0xfebf1000 0               /* tulip_reset */
writel 0xfebf1030 0x2001          /* set csr6 flags  CSR6_ST|CSR6_SR */
writel 0xfebf1020 0xfebf1008      /* set current_tx_desc to its MMIO address,and trigger tulip_desc_write */

-- [ Analysis

(1) setting s->current_rx_desc to tulip MMIO address + CSR(1).
(2) Then tulip_xmit_list_update was executed, and tulip_desc_write wrote a descriptor to its MMIO address+CSR(1).
(3) Tulip_xmit_list_update was called again.  
Then,(2)(3) was executed thousands of times until the stack overflowed.

I found that the same problem could occur in tulip_receive (it can be called by mmio write) and may cause heap overflow:
(1) In tulip_copy_rx_bytes set s->current_rx_desc to its mmio address + CSR(1) via pci_dma_write, then s->rx_frame_len is set to 0.
(2) When tulip_desc_write executes, another tulip_receive is called, s->rx_frame_len  can be set to a big value.
(3) But the first tulip_receive does not end,and  s->rx_frame_len is bigger than s->rx_frame_size, so tulip_copy_rx_bytes causes heap overflow.

-- [ Reporter
Siqi Chen (Shanghai Jiaotong University)

References:
https://bugzilla.redhat.com/show_bug.cgi?id=2120631
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-2962
Comment 2 Hu 2022-08-29 09:59:44 UTC
Upstream issue: https://gitlab.com/qemu-project/qemu/-/issues/1171

Proposed patch: https://lore.kernel.org/qemu-devel/20220821122943.835058-1-zheyuma97@gmail.com/

Tracking as affected:
- SUSE:SLE-15-SP2:Update/qemu             4.2.1
- SUSE:SLE-15-SP3:Update/qemu             5.2.0
- SUSE:SLE-15-SP4:Update/qemu             6.2.0
- openSUSE:Factory/qemu                   7.0.0

Not affected (does not contain hw/net/tulip.c)
- SUSE:SLE-11-SP3:Update/kvm              1.4.2
- SUSE:SLE-12-SP2:Update/qemu             2.6.2
- SUSE:SLE-12-SP3:Update/qemu             2.9.1
- SUSE:SLE-12-SP4:Update/qemu             2.11.2
- SUSE:SLE-15:Update/qemu                 2.11.2
- SUSE:SLE-12-SP5:Update/qemu             3.1.1.1
- SUSE:SLE-15-SP1:Update/qemu             3.1.1.1
Comment 4 Dario Faggioli 2022-09-30 14:12:39 UTC
(In reply to Hu from comment #2)
> Upstream issue: https://gitlab.com/qemu-project/qemu/-/issues/1171
> 
> Proposed patch:
> https://lore.kernel.org/qemu-devel/20220821122943.835058-1-zheyuma97@gmail.
> com/
> 
> Tracking as affected:
> - SUSE:SLE-15-SP2:Update/qemu             4.2.1
> - SUSE:SLE-15-SP3:Update/qemu             5.2.0
> - SUSE:SLE-15-SP4:Update/qemu             6.2.0
> - openSUSE:Factory/qemu                   7.0.0
> 
So, for Factory (and for 15-SP5, which will have 7.1, which is about to get into Factory right in these days) this is fine.

For any products that ships a QEMU version earlier than 7.0 (i.e., all of them!), this means backporting some 22 patches!

See here:
https://bugzilla.redhat.com/show_bug.cgi?id=2120641
https://www.mail-archive.com/qemu-devel@nongnu.org/msg858830.html

I appreciate that the score is quite high, but the risk of adding so much churn to the codebase, even of QEMU 6.2 that we have in SP4 (and I don't even want to think about the others), introduces higher risks than any possible vulnerability in hw/net/tulip.c.

I'll do Factory, and then I'll hand it back to you.
Comment 5 Dario Faggioli 2022-10-04 12:46:36 UTC
(In reply to Dario Faggioli from comment #4)
> I appreciate that the score is quite high, but the risk of adding so much
> churn to the codebase, even of QEMU 6.2 that we have in SP4 (and I don't
> even want to think about the others), introduces higher risks than any
> possible vulnerability in hw/net/tulip.c.
> 
> I'll do Factory, and then I'll hand it back to you.
>
Committed in the devel project: https://build.opensuse.org/request/show/1007904

Will submit to Factory later.

Handing the bug back...
Comment 6 OBSbugzilla Bot 2022-10-04 14:55:02 UTC
This is an autogenerated message for OBS integration:
This bug (1202665) was mentioned in
https://build.opensuse.org/request/show/1007928 Factory / qemu
Comment 7 OBSbugzilla Bot 2022-10-07 16:05:07 UTC
This is an autogenerated message for OBS integration:
This bug (1202665) was mentioned in
https://build.opensuse.org/request/show/1008827 Factory / qemu