* [PATCH] net: check payload length limit for all frames
@ 2020-07-16 19:23 P J P
2020-07-17 0:53 ` Li Qiang
0 siblings, 1 reply; 14+ messages in thread
From: P J P @ 2020-07-16 19:23 UTC (permalink / raw)
To: Jason Wang
Cc: Alexander Bulekov, Dmitry Fleytman, QEMU Developers, Prasad J Pandit
From: Prasad J Pandit <pjp@fedoraproject.org>
While sending packets, the check that packet 'payload_len'
is within 64kB limit, seems to happen only for GSO frames.
It may lead to use-after-free or out-of-bounds access like
issues when sending non-GSO frames. Check the 'payload_len'
limit for all packets, irrespective of the gso type.
Reported-by: Alexander Bulekov <alxndr@bu.edu>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
---
hw/net/net_tx_pkt.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c
index 162f802dd7..e66998a8f9 100644
--- a/hw/net/net_tx_pkt.c
+++ b/hw/net/net_tx_pkt.c
@@ -607,12 +607,10 @@ bool net_tx_pkt_send(struct NetTxPkt *pkt, NetClientState *nc)
* Since underlying infrastructure does not support IP datagrams longer
* than 64K we should drop such packets and don't even try to send
*/
- if (VIRTIO_NET_HDR_GSO_NONE != pkt->virt_hdr.gso_type) {
- if (pkt->payload_len >
- ETH_MAX_IP_DGRAM_LEN -
- pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
- return false;
- }
+ if (pkt->payload_len >
+ ETH_MAX_IP_DGRAM_LEN -
+ pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
+ return false;
}
if (pkt->has_virt_hdr ||
--
2.26.2
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH] net: check payload length limit for all frames
2020-07-16 19:23 [PATCH] net: check payload length limit for all frames P J P
@ 2020-07-17 0:53 ` Li Qiang
2020-07-17 1:21 ` Alexander Bulekov
0 siblings, 1 reply; 14+ messages in thread
From: Li Qiang @ 2020-07-17 0:53 UTC (permalink / raw)
To: P J P
Cc: Alexander Bulekov, Jason Wang, Dmitry Fleytman, QEMU Developers,
Prasad J Pandit
P J P <ppandit@redhat.com> 于2020年7月17日周五 上午3:26写道：
>
> From: Prasad J Pandit <pjp@fedoraproject.org>
>
> While sending packets, the check that packet 'payload_len'
> is within 64kB limit, seems to happen only for GSO frames.
> It may lead to use-after-free or out-of-bounds access like
> issues when sending non-GSO frames. Check the 'payload_len'
> limit for all packets, irrespective of the gso type.
>
Hello Prasad,
Which issue are you trying to solve, any reference linking?
I also send a patch related this part and also a UAF.
Thanks,
Li Qiang
> Reported-by: Alexander Bulekov <alxndr@bu.edu>
> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
> ---
> hw/net/net_tx_pkt.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c
> index 162f802dd7..e66998a8f9 100644
> --- a/hw/net/net_tx_pkt.c
> +++ b/hw/net/net_tx_pkt.c
> @@ -607,12 +607,10 @@ bool net_tx_pkt_send(struct NetTxPkt *pkt, NetClientState *nc)
> * Since underlying infrastructure does not support IP datagrams longer
> * than 64K we should drop such packets and don't even try to send
> */
> - if (VIRTIO_NET_HDR_GSO_NONE != pkt->virt_hdr.gso_type) {
> - if (pkt->payload_len >
> - ETH_MAX_IP_DGRAM_LEN -
> - pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
> - return false;
> - }
> + if (pkt->payload_len >
> + ETH_MAX_IP_DGRAM_LEN -
> + pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
> + return false;
> }
>
> if (pkt->has_virt_hdr ||
> --
> 2.26.2
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] net: check payload length limit for all frames
2020-07-17 0:53 ` Li Qiang
@ 2020-07-17 1:21 ` Alexander Bulekov
2020-07-17 3:13 ` Jason Wang
0 siblings, 1 reply; 14+ messages in thread
From: Alexander Bulekov @ 2020-07-17 1:21 UTC (permalink / raw)
To: Li Qiang
Cc: Prasad J Pandit, Jason Wang, Dmitry Fleytman, QEMU Developers, P J P
On 200717 0853, Li Qiang wrote:
> P J P <ppandit@redhat.com> 于2020年7月17日周五 上午3:26写道：
> >
> > From: Prasad J Pandit <pjp@fedoraproject.org>
> >
> > While sending packets, the check that packet 'payload_len'
> > is within 64kB limit, seems to happen only for GSO frames.
> > It may lead to use-after-free or out-of-bounds access like
> > issues when sending non-GSO frames. Check the 'payload_len'
> > limit for all packets, irrespective of the gso type.
> >
>
> Hello Prasad,
> Which issue are you trying to solve, any reference linking?
>
> I also send a patch related this part and also a UAF.
>
> Thanks,
> Li Qiang
Hi Li, Prasad,
I reported a UAF privately to QEMU-Security in May. I believe the one Li
is referring to is this one https://bugs.launchpad.net/qemu/+bug/1886362
When I saw Prasad's email, I was worried that I reported the same bug
twice, but I can still reproduce LP#1886362 with Prasad's patch.
On the other hand, I cannot reproduce either issue with Li's patch:
Message-Id: <20200716161453.61295-1-liq3ea@163.com>
Based on this, I think there were two distinct issues. Both of the
crashes rely on e1000e tx loopback into e1000e MMIO. Since Li's
patch adds a TX bh, it seems to mitigate such types of issues.
Sorry about any confusion.
-Alex
> > Reported-by: Alexander Bulekov <alxndr@bu.edu>
> > Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
> > ---
> > hw/net/net_tx_pkt.c | 10 ++++------
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c
> > index 162f802dd7..e66998a8f9 100644
> > --- a/hw/net/net_tx_pkt.c
> > +++ b/hw/net/net_tx_pkt.c
> > @@ -607,12 +607,10 @@ bool net_tx_pkt_send(struct NetTxPkt *pkt, NetClientState *nc)
> > * Since underlying infrastructure does not support IP datagrams longer
> > * than 64K we should drop such packets and don't even try to send
> > */
> > - if (VIRTIO_NET_HDR_GSO_NONE != pkt->virt_hdr.gso_type) {
> > - if (pkt->payload_len >
> > - ETH_MAX_IP_DGRAM_LEN -
> > - pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
> > - return false;
> > - }
> > + if (pkt->payload_len >
> > + ETH_MAX_IP_DGRAM_LEN -
> > + pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
> > + return false;
> > }
> >
> > if (pkt->has_virt_hdr ||
> > --
> > 2.26.2
> >
> >
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] net: check payload length limit for all frames
2020-07-17 1:21 ` Alexander Bulekov
@ 2020-07-17 3:13 ` Jason Wang
2020-07-17 5:06 ` P J P
0 siblings, 1 reply; 14+ messages in thread
From: Jason Wang @ 2020-07-17 3:13 UTC (permalink / raw)
To: Alexander Bulekov, Li Qiang
Cc: Prasad J Pandit, Dmitry Fleytman, QEMU Developers, P J P
On 2020/7/17 上午9:21, Alexander Bulekov wrote:
> On 200717 0853, Li Qiang wrote:
>> P J P <ppandit@redhat.com> 于2020年7月17日周五 上午3:26写道：
>>> From: Prasad J Pandit <pjp@fedoraproject.org>
>>>
>>> While sending packets, the check that packet 'payload_len'
>>> is within 64kB limit, seems to happen only for GSO frames.
>>> It may lead to use-after-free or out-of-bounds access like
>>> issues when sending non-GSO frames. Check the 'payload_len'
>>> limit for all packets, irrespective of the gso type.
>>>
>> Hello Prasad,
>> Which issue are you trying to solve, any reference linking?
>>
>> I also send a patch related this part and also a UAF.
>>
>> Thanks,
>> Li Qiang
> Hi Li, Prasad,
> I reported a UAF privately to QEMU-Security in May. I believe the one Li
> is referring to is this one https://bugs.launchpad.net/qemu/+bug/1886362
>
> When I saw Prasad's email, I was worried that I reported the same bug
> twice, but I can still reproduce LP#1886362 with Prasad's patch.
>
> On the other hand, I cannot reproduce either issue with Li's patch:
> Message-Id: <20200716161453.61295-1-liq3ea@163.com>
>
> Based on this, I think there were two distinct issues. Both of the
> crashes rely on e1000e tx loopback into e1000e MMIO. Since Li's
> patch adds a TX bh, it seems to mitigate such types of issues.
>
> Sorry about any confusion.
> -Alex
Could you describe the issue you saw in details? (E.g the calltrace?)
The commit log does not explain where we can get OOB or UAF.
Thanks
>
>>> Reported-by: Alexander Bulekov <alxndr@bu.edu>
>>> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
>>> ---
>>> hw/net/net_tx_pkt.c | 10 ++++------
>>> 1 file changed, 4 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c
>>> index 162f802dd7..e66998a8f9 100644
>>> --- a/hw/net/net_tx_pkt.c
>>> +++ b/hw/net/net_tx_pkt.c
>>> @@ -607,12 +607,10 @@ bool net_tx_pkt_send(struct NetTxPkt *pkt, NetClientState *nc)
>>> * Since underlying infrastructure does not support IP datagrams longer
>>> * than 64K we should drop such packets and don't even try to send
>>> */
>>> - if (VIRTIO_NET_HDR_GSO_NONE != pkt->virt_hdr.gso_type) {
>>> - if (pkt->payload_len >
>>> - ETH_MAX_IP_DGRAM_LEN -
>>> - pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
>>> - return false;
>>> - }
>>> + if (pkt->payload_len >
>>> + ETH_MAX_IP_DGRAM_LEN -
>>> + pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
>>> + return false;
>>> }
>>>
>>> if (pkt->has_virt_hdr ||
>>> --
>>> 2.26.2
>>>
>>>
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] net: check payload length limit for all frames
2020-07-17 3:13 ` Jason Wang
@ 2020-07-17 5:06 ` P J P
2020-07-17 5:51 ` Jason Wang
0 siblings, 1 reply; 14+ messages in thread
From: P J P @ 2020-07-17 5:06 UTC (permalink / raw)
To: Jason Wang; +Cc: Alexander Bulekov, Dmitry Fleytman, Li Qiang, QEMU Developers
[-- Attachment #1: Type: text/plain, Size: 5374 bytes --]
Hello Jason, all
+-- On Fri, 17 Jul 2020, Jason Wang wrote --+
| On 2020/7/17 上午9:21, Alexander Bulekov wrote:
| > On 200717 0853, Li Qiang wrote:
| >> Which issue are you trying to solve, any reference linking?
| >> I also send a patch related this part and also a UAF.
| >
| > I reported a UAF privately to QEMU-Security in May. I believe the one Li
| > is referring to is this one https://bugs.launchpad.net/qemu/+bug/1886362
| >
| > When I saw Prasad's email, I was worried that I reported the same bug
| > twice, but I can still reproduce LP#1886362 with Prasad's patch.
| >
| > On the other hand, I cannot reproduce either issue with Li's patch:
| > Message-Id: <20200716161453.61295-1-liq3ea@163.com>
| >
| > Based on this, I think there were two distinct issues.
Yes, LP#1886362 looks different that the one fixed here.
| Could you describe the issue you saw in details? (E.g the calltrace?) The
| commit log does not explain where we can get OOB or UAF.
I should've included the backtrace in the commit message. It crossed my mind
after I sent the patch. Sorry.
===
1040323==ERROR: AddressSanitizer: heap-use-after-free on address 0x6060000344d8 at pc 0x5571b8fb9ce7 bp 0x7ffede5a2290 sp 0x7ffede5a2280
READ of size 8 at 0x6060000344d8 thread T0
#0 0x5571b8fb9ce6 in e1000e_write_packet_to_guest hw/net/e1000e_core.c:1587
#1 0x5571b8fba8fc in e1000e_receive_iov hw/net/e1000e_core.c:1709
#2 0x5571b8f9cb08 in e1000e_nc_receive_iov hw/net/e1000e.c:213
#3 0x5571b8f90285 in net_tx_pkt_sendv hw/net/net_tx_pkt.c:544
#4 0x5571b8f90aaa in net_tx_pkt_send hw/net/net_tx_pkt.c:620
#5 0x5571b8f90b2e in net_tx_pkt_send_loopback hw/net/net_tx_pkt.c:633
#6 0x5571b8fb3c3b in e1000e_tx_pkt_send hw/net/e1000e_core.c:664
#7 0x5571b8fb43dd in e1000e_process_tx_desc hw/net/e1000e_core.c:743
#8 0x5571b8fb5b4f in e1000e_start_xmit hw/net/e1000e_core.c:934
#9 0x5571b8fbe2ad in e1000e_set_tdt hw/net/e1000e_core.c:2451
#10 0x5571b8fc01e0 in e1000e_core_write hw/net/e1000e_core.c:3265
#11 0x5571b8f9c387 in e1000e_mmio_write hw/net/e1000e.c:109
...
0x6060000344d8 is located 24 bytes inside of 64-byte region [0x6060000344c0,0x606000034500)
freed by thread T0 here:
#0 0x7f89e3b87307 in __interceptor_free (/lib64/libasan.so.6+0xb0307)
#1 0x7f89e37c7a6c in g_free (/lib64/libglib-2.0.so.0+0x58a6c)
#2 0x5571b8f95fc7 in net_rx_pkt_pull_data hw/net/net_rx_pkt.c:103
#3 0x5571b8f969b3 in net_rx_pkt_attach_iovec_ex hw/net/net_rx_pkt.c:158
#4 0x5571b8fba6bc in e1000e_receive_iov hw/net/e1000e_core.c:1695
#5 0x5571b8f9cb08 in e1000e_nc_receive_iov hw/net/e1000e.c:213
#6 0x5571b8f90285 in net_tx_pkt_sendv hw/net/net_tx_pkt.c:544
#7 0x5571b8f90aaa in net_tx_pkt_send hw/net/net_tx_pkt.c:620
#8 0x5571b8f90b2e in net_tx_pkt_send_loopback hw/net/net_tx_pkt.c:633
#9 0x5571b8fb3c3b in e1000e_tx_pkt_send hw/net/e1000e_core.c:664
#10 0x5571b8fb43dd in e1000e_process_tx_desc hw/net/e1000e_core.c:743
#11 0x5571b8fb5b4f in e1000e_start_xmit hw/net/e1000e_core.c:934
#12 0x5571b8fbe011 in e1000e_set_tctl hw/net/e1000e_core.c:2431
#13 0x5571b8fc01e0 in e1000e_core_write hw/net/e1000e_core.c:3265
#14 0x5571b8f9c387 in e1000e_mmio_write hw/net/e1000e.c:109
...
previously allocated by thread T0 here:
#0 0x7f89e3b87667 in __interceptor_malloc (/lib64/libasan.so.6+0xb0667)
#1 0x7f89e37c7978 in g_malloc (/lib64/libglib-2.0.so.0+0x58978)
#2 0x5571b8f95fc7 in net_rx_pkt_pull_data hw/net/net_rx_pkt.c:103
#3 0x5571b8f969b3 in net_rx_pkt_attach_iovec_ex hw/net/net_rx_pkt.c:158
#4 0x5571b8fba6bc in e1000e_receive_iov hw/net/e1000e_core.c:1695
#5 0x5571b8f9cb08 in e1000e_nc_receive_iov hw/net/e1000e.c:213
#6 0x5571b8f90285 in net_tx_pkt_sendv hw/net/net_tx_pkt.c:544
#7 0x5571b8f90aaa in net_tx_pkt_send hw/net/net_tx_pkt.c:620
#8 0x5571b8f90b2e in net_tx_pkt_send_loopback hw/net/net_tx_pkt.c:633
#9 0x5571b8fb3c3b in e1000e_tx_pkt_send hw/net/e1000e_core.c:664
#10 0x5571b8fb43dd in e1000e_process_tx_desc hw/net/e1000e_core.c:743
#11 0x5571b8fb5b4f in e1000e_start_xmit hw/net/e1000e_core.c:934
#12 0x5571b8fbe2ad in e1000e_set_tdt hw/net/e1000e_core.c:2451
#13 0x5571b8fc01e0 in e1000e_core_write hw/net/e1000e_core.c:3265
#14 0x5571b8f9c387 in e1000e_mmio_write hw/net/e1000e.c:109
===
| >>> --- a/hw/net/net_tx_pkt.c
| >>> +++ b/hw/net/net_tx_pkt.c
| >>> @@ -607,12 +607,10 @@ bool net_tx_pkt_send(struct NetTxPkt *pkt,
| >>> NetClientState *nc)
| >>> * Since underlying infrastructure does not support IP datagrams
| >>> longer
| >>> * than 64K we should drop such packets and don't even try to send
| >>> */
| >>> - if (VIRTIO_NET_HDR_GSO_NONE != pkt->virt_hdr.gso_type) {
| >>> - if (pkt->payload_len >
| >>> - ETH_MAX_IP_DGRAM_LEN -
| >>> - pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
| >>> - return false;
| >>> - }
| >>> + if (pkt->payload_len >
| >>> + ETH_MAX_IP_DGRAM_LEN -
| >>> + pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
| >>> + return false;
| >>> }
Nevertheless, checking 'payload_len' for all packets irrespective of the
'gso_type' does seem reasonable.
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] net: check payload length limit for all frames
2020-07-17 5:06 ` P J P
@ 2020-07-17 5:51 ` Jason Wang
2020-07-17 9:08 ` P J P
0 siblings, 1 reply; 14+ messages in thread
From: Jason Wang @ 2020-07-17 5:51 UTC (permalink / raw)
To: P J P; +Cc: Alexander Bulekov, Dmitry Fleytman, Li Qiang, QEMU Developers
On 2020/7/17 下午1:06, P J P wrote:
> Hello Jason, all
>
> +-- On Fri, 17 Jul 2020, Jason Wang wrote --+
> | On 2020/7/17 上午9:21, Alexander Bulekov wrote:
> | > On 200717 0853, Li Qiang wrote:
> | >> Which issue are you trying to solve, any reference linking?
> | >> I also send a patch related this part and also a UAF.
> | >
> | > I reported a UAF privately to QEMU-Security in May. I believe the one Li
> | > is referring to is this one https://bugs.launchpad.net/qemu/+bug/1886362
> | >
> | > When I saw Prasad's email, I was worried that I reported the same bug
> | > twice, but I can still reproduce LP#1886362 with Prasad's patch.
> | >
> | > On the other hand, I cannot reproduce either issue with Li's patch:
> | > Message-Id: <20200716161453.61295-1-liq3ea@163.com>
> | >
> | > Based on this, I think there were two distinct issues.
>
> Yes, LP#1886362 looks different that the one fixed here.
>
> | Could you describe the issue you saw in details? (E.g the calltrace?) The
> | commit log does not explain where we can get OOB or UAF.
>
> I should've included the backtrace in the commit message. It crossed my mind
> after I sent the patch. Sorry.
Thanks but I don't see a direct relation between 64K limit and this
calltrace.
Maybe you can elaborate more on this?
Thanks
>
> ===
> 1040323==ERROR: AddressSanitizer: heap-use-after-free on address 0x6060000344d8 at pc 0x5571b8fb9ce7 bp 0x7ffede5a2290 sp 0x7ffede5a2280
> READ of size 8 at 0x6060000344d8 thread T0
> #0 0x5571b8fb9ce6 in e1000e_write_packet_to_guest hw/net/e1000e_core.c:1587
> #1 0x5571b8fba8fc in e1000e_receive_iov hw/net/e1000e_core.c:1709
> #2 0x5571b8f9cb08 in e1000e_nc_receive_iov hw/net/e1000e.c:213
> #3 0x5571b8f90285 in net_tx_pkt_sendv hw/net/net_tx_pkt.c:544
> #4 0x5571b8f90aaa in net_tx_pkt_send hw/net/net_tx_pkt.c:620
> #5 0x5571b8f90b2e in net_tx_pkt_send_loopback hw/net/net_tx_pkt.c:633
> #6 0x5571b8fb3c3b in e1000e_tx_pkt_send hw/net/e1000e_core.c:664
> #7 0x5571b8fb43dd in e1000e_process_tx_desc hw/net/e1000e_core.c:743
> #8 0x5571b8fb5b4f in e1000e_start_xmit hw/net/e1000e_core.c:934
> #9 0x5571b8fbe2ad in e1000e_set_tdt hw/net/e1000e_core.c:2451
> #10 0x5571b8fc01e0 in e1000e_core_write hw/net/e1000e_core.c:3265
> #11 0x5571b8f9c387 in e1000e_mmio_write hw/net/e1000e.c:109
> ...
> 0x6060000344d8 is located 24 bytes inside of 64-byte region [0x6060000344c0,0x606000034500)
> freed by thread T0 here:
> #0 0x7f89e3b87307 in __interceptor_free (/lib64/libasan.so.6+0xb0307)
> #1 0x7f89e37c7a6c in g_free (/lib64/libglib-2.0.so.0+0x58a6c)
> #2 0x5571b8f95fc7 in net_rx_pkt_pull_data hw/net/net_rx_pkt.c:103
> #3 0x5571b8f969b3 in net_rx_pkt_attach_iovec_ex hw/net/net_rx_pkt.c:158
> #4 0x5571b8fba6bc in e1000e_receive_iov hw/net/e1000e_core.c:1695
> #5 0x5571b8f9cb08 in e1000e_nc_receive_iov hw/net/e1000e.c:213
> #6 0x5571b8f90285 in net_tx_pkt_sendv hw/net/net_tx_pkt.c:544
> #7 0x5571b8f90aaa in net_tx_pkt_send hw/net/net_tx_pkt.c:620
> #8 0x5571b8f90b2e in net_tx_pkt_send_loopback hw/net/net_tx_pkt.c:633
> #9 0x5571b8fb3c3b in e1000e_tx_pkt_send hw/net/e1000e_core.c:664
> #10 0x5571b8fb43dd in e1000e_process_tx_desc hw/net/e1000e_core.c:743
> #11 0x5571b8fb5b4f in e1000e_start_xmit hw/net/e1000e_core.c:934
> #12 0x5571b8fbe011 in e1000e_set_tctl hw/net/e1000e_core.c:2431
> #13 0x5571b8fc01e0 in e1000e_core_write hw/net/e1000e_core.c:3265
> #14 0x5571b8f9c387 in e1000e_mmio_write hw/net/e1000e.c:109
> ...
> previously allocated by thread T0 here:
> #0 0x7f89e3b87667 in __interceptor_malloc (/lib64/libasan.so.6+0xb0667)
> #1 0x7f89e37c7978 in g_malloc (/lib64/libglib-2.0.so.0+0x58978)
> #2 0x5571b8f95fc7 in net_rx_pkt_pull_data hw/net/net_rx_pkt.c:103
> #3 0x5571b8f969b3 in net_rx_pkt_attach_iovec_ex hw/net/net_rx_pkt.c:158
> #4 0x5571b8fba6bc in e1000e_receive_iov hw/net/e1000e_core.c:1695
> #5 0x5571b8f9cb08 in e1000e_nc_receive_iov hw/net/e1000e.c:213
> #6 0x5571b8f90285 in net_tx_pkt_sendv hw/net/net_tx_pkt.c:544
> #7 0x5571b8f90aaa in net_tx_pkt_send hw/net/net_tx_pkt.c:620
> #8 0x5571b8f90b2e in net_tx_pkt_send_loopback hw/net/net_tx_pkt.c:633
> #9 0x5571b8fb3c3b in e1000e_tx_pkt_send hw/net/e1000e_core.c:664
> #10 0x5571b8fb43dd in e1000e_process_tx_desc hw/net/e1000e_core.c:743
> #11 0x5571b8fb5b4f in e1000e_start_xmit hw/net/e1000e_core.c:934
> #12 0x5571b8fbe2ad in e1000e_set_tdt hw/net/e1000e_core.c:2451
> #13 0x5571b8fc01e0 in e1000e_core_write hw/net/e1000e_core.c:3265
> #14 0x5571b8f9c387 in e1000e_mmio_write hw/net/e1000e.c:109
> ===
>
> | >>> --- a/hw/net/net_tx_pkt.c
> | >>> +++ b/hw/net/net_tx_pkt.c
> | >>> @@ -607,12 +607,10 @@ bool net_tx_pkt_send(struct NetTxPkt *pkt,
> | >>> NetClientState *nc)
> | >>> * Since underlying infrastructure does not support IP datagrams
> | >>> longer
> | >>> * than 64K we should drop such packets and don't even try to send
> | >>> */
> | >>> - if (VIRTIO_NET_HDR_GSO_NONE != pkt->virt_hdr.gso_type) {
> | >>> - if (pkt->payload_len >
> | >>> - ETH_MAX_IP_DGRAM_LEN -
> | >>> - pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
> | >>> - return false;
> | >>> - }
> | >>> + if (pkt->payload_len >
> | >>> + ETH_MAX_IP_DGRAM_LEN -
> | >>> + pkt->vec[NET_TX_PKT_L3HDR_FRAG].iov_len) {
> | >>> + return false;
> | >>> }
>
> Nevertheless, checking 'payload_len' for all packets irrespective of the
> 'gso_type' does seem reasonable.
>
>
> Thank you.
> --
> Prasad J Pandit / Red Hat Product Security Team
> 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] net: check payload length limit for all frames
2020-07-17 5:51 ` Jason Wang
@ 2020-07-17 9:08 ` P J P
2020-07-17 10:02 ` Li Qiang
0 siblings, 1 reply; 14+ messages in thread
From: P J P @ 2020-07-17 9:08 UTC (permalink / raw)
To: Jason Wang; +Cc: Alexander Bulekov, Dmitry Fleytman, Li Qiang, QEMU Developers
+-- On Fri, 17 Jul 2020, Jason Wang wrote --+
| Thanks but I don't see a direct relation between 64K limit and this
| calltrace. Maybe you can elaborate more on this?
The use-after-free is not function of the size per say; The reproducer given
sends large(>64k) packets via loopback interface with gso_type=none(0). The
proposed patch helps to fix it. The large size & payload_len may result in
other oob kind of access issues too I think.
@Alex, would it be possible to share the reproduces on the upstream bug
LP#1886362?
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] net: check payload length limit for all frames
2020-07-17 9:08 ` P J P
@ 2020-07-17 10:02 ` Li Qiang
2020-07-20 2:24 ` P J P
0 siblings, 1 reply; 14+ messages in thread
From: Li Qiang @ 2020-07-17 10:02 UTC (permalink / raw)
To: P J P; +Cc: Alexander Bulekov, Jason Wang, Dmitry Fleytman, QEMU Developers
P J P <ppandit@redhat.com> 于2020年7月17日周五 下午5:09写道：
>
> +-- On Fri, 17 Jul 2020, Jason Wang wrote --+
> | Thanks but I don't see a direct relation between 64K limit and this
> | calltrace. Maybe you can elaborate more on this?
>
> The use-after-free is not function of the size per say; The reproducer given
> sends large(>64k) packets via loopback interface with gso_type=none(0). The
> proposed patch helps to fix it. The large size & payload_len may result in
> other oob kind of access issues too I think.
>
> @Alex, would it be possible to share the reproduces on the upstream bug
> LP#1886362?
The reproducer of LP#1886362 is here:
--> https://bugs.launchpad.net/qemu/+bug/1886362
Maybe you mean the reproducer of your patch?
If you or Alex could share it, I'm glad to analysis this issue.
Thanks,
Li Qiang
>
> Thank you.
> --
> Prasad J Pandit / Red Hat Product Security Team
> 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] net: check payload length limit for all frames
2020-07-17 10:02 ` Li Qiang
@ 2020-07-20 2:24 ` P J P
2020-07-20 3:33 ` Alexander Bulekov
0 siblings, 1 reply; 14+ messages in thread
From: P J P @ 2020-07-20 2:24 UTC (permalink / raw)
To: Alexander Bulekov; +Cc: Jason Wang, Dmitry Fleytman, Li Qiang, QEMU Developers
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
+-- On Fri, 17 Jul 2020, Li Qiang wrote --+
| P J P <ppandit@redhat.com> 于2020年7月17日周五 下午5:09写道：
| > @Alex, would it be possible to share the reproduces on the upstream bug
| > LP#1886362?
|
| Maybe you mean the reproducer of your patch?
Yes.
| If you or Alex could share it, I'm glad to analysis this issue.
@Alex ...?
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] net: check payload length limit for all frames
2020-07-20 2:24 ` P J P
@ 2020-07-20 3:33 ` Alexander Bulekov
2020-07-20 11:46 ` Li Qiang
0 siblings, 1 reply; 14+ messages in thread
From: Alexander Bulekov @ 2020-07-20 3:33 UTC (permalink / raw)
To: P J P; +Cc: Jason Wang, Dmitry Fleytman, Li Qiang, QEMU Developers
On 200720 0754, P J P wrote:
> +-- On Fri, 17 Jul 2020, Li Qiang wrote --+
> | P J P <ppandit@redhat.com> 于2020年7月17日周五 下午5:09写道：
> | > @Alex, would it be possible to share the reproduces on the upstream bug
> | > LP#1886362?
> |
> | Maybe you mean the reproducer of your patch?
>
> Yes.
>
> | If you or Alex could share it, I'm glad to analysis this issue.
>
> @Alex ...?
Happy to share it, as long as it is fine with qemu-security:
I reduced it further, from the original that I sent:
cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc-q35-5.0 \
-netdev user,id=qtest-bn0 -device e1000e,netdev=qtest-bn0 \
-display none -nodefaults -nographic -qtest stdio
outl 0xcf8 0x80000810
outl 0xcfc 0xe0000000
outl 0xcf8 0x80000804
outw 0xcfc 0x7
write 0xe0000758 0x4 0xfffff1ff
write 0xe0000760 0x6 0xffffdf000000
write 0xe0000768 0x4 0x0efffff1
write 0xe0005008 0x4 0x18ffff27
write 0xe0000c 0x1 0x66
write 0xe03320 0x1 0xff
write 0xe03620 0x1 0xff
write 0xe00000f3 0x1 0xdf
write 0xe0000100 0x6 0xdfffffdf0000
write 0xe0000110 0x5 0xdfffffdf00
write 0xe000011a 0x3 0xffffff
write 0xe0000128 0x5 0x7e00ffffff
write 0xe0000403 0x1 0xdf
write 0xe0000420 0x4 0xdfffffdf
write 0xe000042a 0x3 0xffffff
write 0xe0000438 0x1 0x7e
EOF
Here are the ASAN Stacktraces:
=================================================================
==7909==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000032f18 at pc 0x561dd4409b96 bp 0x7ffdfe983030 sp 0x7ffdfe983028
READ of size 8 at 0x606000032f18 thread T0
#0 0x561dd4409b95 in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1587:41
#1 0x561dd4403fa2 in e1000e_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709:9
#2 0x561dd43fd91a in e1000e_nc_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e.c:213:12
#3 0x561dd43c82e7 in net_tx_pkt_sendv /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:553:9
#4 0x561dd43c65e6 in net_tx_pkt_send /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:629:9
#5 0x561dd43c9c78 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:642:11
#6 0x561dd4472cf6 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664:16
#7 0x561dd446f296 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743:17
#8 0x561dd446ce68 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9
#9 0x561dd445635d in e1000e_set_tdt /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9
#10 0x561dd440f19e in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3265:9
#11 0x561dd43f77b7 in e1000e_mmio_write /home/alxndr/Development/qemu/hw/net/e1000e.c:109:5
#12 0x561dd2ff62a3 in memory_region_write_accessor /home/alxndr/Development/qemu/softmmu/memory.c:483:5
#13 0x561dd2ff5747 in access_with_adjusted_size /home/alxndr/Development/qemu/softmmu/memory.c:544:18
#14 0x561dd2ff3366 in memory_region_dispatch_write /home/alxndr/Development/qemu/softmmu/memory.c:1465:16
#15 0x561dd23a5476 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3176:23
#16 0x561dd238de86 in flatview_write /home/alxndr/Development/qemu/exec.c:3216:14
#17 0x561dd238d9a7 in address_space_write /home/alxndr/Development/qemu/exec.c:3307:18
#18 0x561dd30a43b1 in qtest_process_command /home/alxndr/Development/qemu/softmmu/qtest.c:567:9
#19 0x561dd3094b38 in qtest_process_inbuf /home/alxndr/Development/qemu/softmmu/qtest.c:710:9
#20 0x561dd30937c5 in qtest_read /home/alxndr/Development/qemu/softmmu/qtest.c:722:5
#21 0x561dd5f33993 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/chardev/char.c:188:9
#22 0x561dd5f33b17 in qemu_chr_be_write /home/alxndr/Development/qemu/chardev/char.c:200:9
#23 0x561dd5f47e03 in fd_chr_read /home/alxndr/Development/qemu/chardev/char-fd.c:68:9
#24 0x561dd609c1c4 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/io/channel-watch.c:84:12
#25 0x7f58c0237897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897)
#26 0x561dd6495f2b in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:217:9
#27 0x561dd649365b in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:240:5
#28 0x561dd6492ff4 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:516:11
#29 0x561dd30b4e00 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1676:9
#30 0x561dd60d3fb1 in main /home/alxndr/Development/qemu/softmmu/main.c:49:5
#31 0x7f58bedbde0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16
#32 0x561dd2298919 in _start (/home/alxndr/Development/qemu/build-asan/i386-softmmu/qemu-system-i386+0x2b3d919)
0x606000032f18 is located 24 bytes inside of 64-byte region [0x606000032f00,0x606000032f40)
freed by thread T0 here:
#0 0x561dd231108d in free (/home/alxndr/Development/qemu/build-asan/i386-softmmu/qemu-system-i386+0x2bb608d)
#1 0x561dd43e3129 in net_rx_pkt_iovec_realloc /home/alxndr/Development/qemu/hw/net/net_rx_pkt.c:80:9
#2 0x561dd43d0666 in net_rx_pkt_pull_data /home/alxndr/Development/qemu/hw/net/net_rx_pkt.c:103:9
#3 0x561dd43d2cf6 in net_rx_pkt_attach_iovec_ex /home/alxndr/Development/qemu/hw/net/net_rx_pkt.c:158:5
#4 0x561dd440360f in e1000e_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1695:5
#5 0x561dd43fd91a in e1000e_nc_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e.c:213:12
#6 0x561dd43c82e7 in net_tx_pkt_sendv /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:553:9
#7 0x561dd43c65e6 in net_tx_pkt_send /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:629:9
#8 0x561dd43c9c78 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:642:11
#9 0x561dd4472cf6 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664:16
#10 0x561dd446f296 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743:17
#11 0x561dd446ce68 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9
#12 0x561dd4453602 in e1000e_set_tctl /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2431:9
#13 0x561dd440f19e in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3265:9
#14 0x561dd43f77b7 in e1000e_mmio_write /home/alxndr/Development/qemu/hw/net/e1000e.c:109:5
#15 0x561dd2ff62a3 in memory_region_write_accessor /home/alxndr/Development/qemu/softmmu/memory.c:483:5
#16 0x561dd2ff5747 in access_with_adjusted_size /home/alxndr/Development/qemu/softmmu/memory.c:544:18
#17 0x561dd2ff3366 in memory_region_dispatch_write /home/alxndr/Development/qemu/softmmu/memory.c:1465:16
#18 0x561dd23a5476 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3176:23
#19 0x561dd238de86 in flatview_write /home/alxndr/Development/qemu/exec.c:3216:14
#20 0x561dd238d9a7 in address_space_write /home/alxndr/Development/qemu/exec.c:3307:18
#21 0x561dd238e265 in address_space_rw /home/alxndr/Development/qemu/exec.c:3317:16
#22 0x561dd442e72e in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:87:18
#23 0x561dd442e053 in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:110:12
#24 0x561dd442df8f in pci_dma_rw /home/alxndr/Development/qemu/include/hw/pci/pci.h:790:5
#25 0x561dd442c24f in pci_dma_write /home/alxndr/Development/qemu/include/hw/pci/pci.h:803:12
#26 0x561dd442af8f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1412:9
#27 0x561dd4409a0b in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1582:21
#28 0x561dd4403fa2 in e1000e_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709:9
#29 0x561dd43fd91a in e1000e_nc_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e.c:213:12
previously allocated by thread T0 here:
#0 0x561dd231130d in malloc (/home/alxndr/Development/qemu/build-asan/i386-softmmu/qemu-system-i386+0x2bb630d)
#1 0x7f58c023d500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500)
#2 0x561dd43d0666 in net_rx_pkt_pull_data /home/alxndr/Development/qemu/hw/net/net_rx_pkt.c:103:9
#3 0x561dd43d2cf6 in net_rx_pkt_attach_iovec_ex /home/alxndr/Development/qemu/hw/net/net_rx_pkt.c:158:5
#4 0x561dd440360f in e1000e_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1695:5
#5 0x561dd43fd91a in e1000e_nc_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e.c:213:12
#6 0x561dd43c82e7 in net_tx_pkt_sendv /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:553:9
#7 0x561dd43c65e6 in net_tx_pkt_send /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:629:9
#8 0x561dd43c9c78 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:642:11
#9 0x561dd4472cf6 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664:16
#10 0x561dd446f296 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743:17
#11 0x561dd446ce68 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9
#12 0x561dd445635d in e1000e_set_tdt /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9
#13 0x561dd440f19e in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3265:9
#14 0x561dd43f77b7 in e1000e_mmio_write /home/alxndr/Development/qemu/hw/net/e1000e.c:109:5
#15 0x561dd2ff62a3 in memory_region_write_accessor /home/alxndr/Development/qemu/softmmu/memory.c:483:5
#16 0x561dd2ff5747 in access_with_adjusted_size /home/alxndr/Development/qemu/softmmu/memory.c:544:18
#17 0x561dd2ff3366 in memory_region_dispatch_write /home/alxndr/Development/qemu/softmmu/memory.c:1465:16
#18 0x561dd23a5476 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3176:23
#19 0x561dd238de86 in flatview_write /home/alxndr/Development/qemu/exec.c:3216:14
#20 0x561dd238d9a7 in address_space_write /home/alxndr/Development/qemu/exec.c:3307:18
#21 0x561dd30a43b1 in qtest_process_command /home/alxndr/Development/qemu/softmmu/qtest.c:567:9
#22 0x561dd3094b38 in qtest_process_inbuf /home/alxndr/Development/qemu/softmmu/qtest.c:710:9
#23 0x561dd30937c5 in qtest_read /home/alxndr/Development/qemu/softmmu/qtest.c:722:5
#24 0x561dd5f33993 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/chardev/char.c:188:9
#25 0x561dd5f33b17 in qemu_chr_be_write /home/alxndr/Development/qemu/chardev/char.c:200:9
#26 0x561dd5f47e03 in fd_chr_read /home/alxndr/Development/qemu/chardev/char-fd.c:68:9
#27 0x561dd609c1c4 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/io/channel-watch.c:84:12
#28 0x7f58c0237897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897)
Let me know if I can help with anything else!
-Alex
> Thank you.
> --
> Prasad J Pandit / Red Hat Product Security Team
> 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] net: check payload length limit for all frames
2020-07-20 3:33 ` Alexander Bulekov
@ 2020-07-20 11:46 ` Li Qiang
2020-07-20 12:57 ` P J P
2020-07-20 14:02 ` Alexander Bulekov
0 siblings, 2 replies; 14+ messages in thread
From: Li Qiang @ 2020-07-20 11:46 UTC (permalink / raw)
To: Alexander Bulekov; +Cc: Jason Wang, Dmitry Fleytman, QEMU Developers, P J P
Alexander Bulekov <alxndr@bu.edu> 于2020年7月20日周一 上午11:33写道：
>
> On 200720 0754, P J P wrote:
> > +-- On Fri, 17 Jul 2020, Li Qiang wrote --+
> > | P J P <ppandit@redhat.com> 于2020年7月17日周五 下午5:09写道：
> > | > @Alex, would it be possible to share the reproduces on the upstream bug
> > | > LP#1886362?
> > |
> > | Maybe you mean the reproducer of your patch?
> >
> > Yes.
> >
> > | If you or Alex could share it, I'm glad to analysis this issue.
> >
> > @Alex ...?
>
> Happy to share it, as long as it is fine with qemu-security:
> I reduced it further, from the original that I sent:
>
> cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc-q35-5.0 \
> -netdev user,id=qtest-bn0 -device e1000e,netdev=qtest-bn0 \
> -display none -nodefaults -nographic -qtest stdio
> outl 0xcf8 0x80000810
> outl 0xcfc 0xe0000000
> outl 0xcf8 0x80000804
> outw 0xcfc 0x7
> write 0xe0000758 0x4 0xfffff1ff
> write 0xe0000760 0x6 0xffffdf000000
> write 0xe0000768 0x4 0x0efffff1
> write 0xe0005008 0x4 0x18ffff27
> write 0xe0000c 0x1 0x66
> write 0xe03320 0x1 0xff
> write 0xe03620 0x1 0xff
> write 0xe00000f3 0x1 0xdf
> write 0xe0000100 0x6 0xdfffffdf0000
> write 0xe0000110 0x5 0xdfffffdf00
> write 0xe000011a 0x3 0xffffff
> write 0xe0000128 0x5 0x7e00ffffff
> write 0xe0000403 0x1 0xdf
> write 0xe0000420 0x4 0xdfffffdf
> write 0xe000042a 0x3 0xffffff
> write 0xe0000438 0x1 0x7e
> EOF
>
> Here are the ASAN Stacktraces:
>
> =================================================================
> ==7909==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000032f18 at pc 0x561dd4409b96 bp 0x7ffdfe983030 sp 0x7ffdfe983028
> READ of size 8 at 0x606000032f18 thread T0
> #0 0x561dd4409b95 in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1587:41
> #1 0x561dd4403fa2 in e1000e_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709:9
> #2 0x561dd43fd91a in e1000e_nc_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e.c:213:12
> #3 0x561dd43c82e7 in net_tx_pkt_sendv /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:553:9
> #4 0x561dd43c65e6 in net_tx_pkt_send /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:629:9
> #5 0x561dd43c9c78 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:642:11
> #6 0x561dd4472cf6 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664:16
> #7 0x561dd446f296 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743:17
> #8 0x561dd446ce68 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9
> #9 0x561dd445635d in e1000e_set_tdt /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9
> #10 0x561dd440f19e in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3265:9
> #11 0x561dd43f77b7 in e1000e_mmio_write /home/alxndr/Development/qemu/hw/net/e1000e.c:109:5
> #12 0x561dd2ff62a3 in memory_region_write_accessor /home/alxndr/Development/qemu/softmmu/memory.c:483:5
> #13 0x561dd2ff5747 in access_with_adjusted_size /home/alxndr/Development/qemu/softmmu/memory.c:544:18
> #14 0x561dd2ff3366 in memory_region_dispatch_write /home/alxndr/Development/qemu/softmmu/memory.c:1465:16
> #15 0x561dd23a5476 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3176:23
> #16 0x561dd238de86 in flatview_write /home/alxndr/Development/qemu/exec.c:3216:14
> #17 0x561dd238d9a7 in address_space_write /home/alxndr/Development/qemu/exec.c:3307:18
> #18 0x561dd30a43b1 in qtest_process_command /home/alxndr/Development/qemu/softmmu/qtest.c:567:9
> #19 0x561dd3094b38 in qtest_process_inbuf /home/alxndr/Development/qemu/softmmu/qtest.c:710:9
> #20 0x561dd30937c5 in qtest_read /home/alxndr/Development/qemu/softmmu/qtest.c:722:5
> #21 0x561dd5f33993 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/chardev/char.c:188:9
> #22 0x561dd5f33b17 in qemu_chr_be_write /home/alxndr/Development/qemu/chardev/char.c:200:9
> #23 0x561dd5f47e03 in fd_chr_read /home/alxndr/Development/qemu/chardev/char-fd.c:68:9
> #24 0x561dd609c1c4 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/io/channel-watch.c:84:12
> #25 0x7f58c0237897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897)
> #26 0x561dd6495f2b in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:217:9
> #27 0x561dd649365b in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:240:5
> #28 0x561dd6492ff4 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:516:11
> #29 0x561dd30b4e00 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1676:9
> #30 0x561dd60d3fb1 in main /home/alxndr/Development/qemu/softmmu/main.c:49:5
> #31 0x7f58bedbde0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16
> #32 0x561dd2298919 in _start (/home/alxndr/Development/qemu/build-asan/i386-softmmu/qemu-system-i386+0x2b3d919)
>
> 0x606000032f18 is located 24 bytes inside of 64-byte region [0x606000032f00,0x606000032f40)
> freed by thread T0 here:
> #0 0x561dd231108d in free (/home/alxndr/Development/qemu/build-asan/i386-softmmu/qemu-system-i386+0x2bb608d)
> #1 0x561dd43e3129 in net_rx_pkt_iovec_realloc /home/alxndr/Development/qemu/hw/net/net_rx_pkt.c:80:9
> #2 0x561dd43d0666 in net_rx_pkt_pull_data /home/alxndr/Development/qemu/hw/net/net_rx_pkt.c:103:9
> #3 0x561dd43d2cf6 in net_rx_pkt_attach_iovec_ex /home/alxndr/Development/qemu/hw/net/net_rx_pkt.c:158:5
> #4 0x561dd440360f in e1000e_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1695:5
> #5 0x561dd43fd91a in e1000e_nc_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e.c:213:12
> #6 0x561dd43c82e7 in net_tx_pkt_sendv /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:553:9
> #7 0x561dd43c65e6 in net_tx_pkt_send /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:629:9
> #8 0x561dd43c9c78 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:642:11
> #9 0x561dd4472cf6 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664:16
> #10 0x561dd446f296 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743:17
> #11 0x561dd446ce68 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9
> #12 0x561dd4453602 in e1000e_set_tctl /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2431:9
> #13 0x561dd440f19e in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3265:9
> #14 0x561dd43f77b7 in e1000e_mmio_write /home/alxndr/Development/qemu/hw/net/e1000e.c:109:5
> #15 0x561dd2ff62a3 in memory_region_write_accessor /home/alxndr/Development/qemu/softmmu/memory.c:483:5
> #16 0x561dd2ff5747 in access_with_adjusted_size /home/alxndr/Development/qemu/softmmu/memory.c:544:18
> #17 0x561dd2ff3366 in memory_region_dispatch_write /home/alxndr/Development/qemu/softmmu/memory.c:1465:16
> #18 0x561dd23a5476 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3176:23
> #19 0x561dd238de86 in flatview_write /home/alxndr/Development/qemu/exec.c:3216:14
> #20 0x561dd238d9a7 in address_space_write /home/alxndr/Development/qemu/exec.c:3307:18
> #21 0x561dd238e265 in address_space_rw /home/alxndr/Development/qemu/exec.c:3317:16
> #22 0x561dd442e72e in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:87:18
> #23 0x561dd442e053 in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:110:12
> #24 0x561dd442df8f in pci_dma_rw /home/alxndr/Development/qemu/include/hw/pci/pci.h:790:5
> #25 0x561dd442c24f in pci_dma_write /home/alxndr/Development/qemu/include/hw/pci/pci.h:803:12
> #26 0x561dd442af8f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1412:9
> #27 0x561dd4409a0b in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1582:21
> #28 0x561dd4403fa2 in e1000e_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709:9
> #29 0x561dd43fd91a in e1000e_nc_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e.c:213:12
>
This seems is the same issue as LP#1886362 .
Look at the free path.
Here the 'e1000e_write_to_rx_buffers' trigger DMA and then go to
address space dispatch. So the DMA is not RAM but a MMIO range.
Then we go to another send path, and in that we frees the 'iov'.
Alex do you tried my patch to solve LP#1886362 ?
I have tried it and it seems no this UAF triggered.
Thanks,
Li Qiang
> previously allocated by thread T0 here:
> #0 0x561dd231130d in malloc (/home/alxndr/Development/qemu/build-asan/i386-softmmu/qemu-system-i386+0x2bb630d)
> #1 0x7f58c023d500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500)
> #2 0x561dd43d0666 in net_rx_pkt_pull_data /home/alxndr/Development/qemu/hw/net/net_rx_pkt.c:103:9
> #3 0x561dd43d2cf6 in net_rx_pkt_attach_iovec_ex /home/alxndr/Development/qemu/hw/net/net_rx_pkt.c:158:5
> #4 0x561dd440360f in e1000e_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1695:5
> #5 0x561dd43fd91a in e1000e_nc_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e.c:213:12
> #6 0x561dd43c82e7 in net_tx_pkt_sendv /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:553:9
> #7 0x561dd43c65e6 in net_tx_pkt_send /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:629:9
> #8 0x561dd43c9c78 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:642:11
> #9 0x561dd4472cf6 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664:16
> #10 0x561dd446f296 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743:17
> #11 0x561dd446ce68 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9
> #12 0x561dd445635d in e1000e_set_tdt /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9
> #13 0x561dd440f19e in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3265:9
> #14 0x561dd43f77b7 in e1000e_mmio_write /home/alxndr/Development/qemu/hw/net/e1000e.c:109:5
> #15 0x561dd2ff62a3 in memory_region_write_accessor /home/alxndr/Development/qemu/softmmu/memory.c:483:5
> #16 0x561dd2ff5747 in access_with_adjusted_size /home/alxndr/Development/qemu/softmmu/memory.c:544:18
> #17 0x561dd2ff3366 in memory_region_dispatch_write /home/alxndr/Development/qemu/softmmu/memory.c:1465:16
> #18 0x561dd23a5476 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3176:23
> #19 0x561dd238de86 in flatview_write /home/alxndr/Development/qemu/exec.c:3216:14
> #20 0x561dd238d9a7 in address_space_write /home/alxndr/Development/qemu/exec.c:3307:18
> #21 0x561dd30a43b1 in qtest_process_command /home/alxndr/Development/qemu/softmmu/qtest.c:567:9
> #22 0x561dd3094b38 in qtest_process_inbuf /home/alxndr/Development/qemu/softmmu/qtest.c:710:9
> #23 0x561dd30937c5 in qtest_read /home/alxndr/Development/qemu/softmmu/qtest.c:722:5
> #24 0x561dd5f33993 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/chardev/char.c:188:9
> #25 0x561dd5f33b17 in qemu_chr_be_write /home/alxndr/Development/qemu/chardev/char.c:200:9
> #26 0x561dd5f47e03 in fd_chr_read /home/alxndr/Development/qemu/chardev/char-fd.c:68:9
> #27 0x561dd609c1c4 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/io/channel-watch.c:84:12
> #28 0x7f58c0237897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897)
>
> Let me know if I can help with anything else!
> -Alex
>
> > Thank you.
> > --
> > Prasad J Pandit / Red Hat Product Security Team
> > 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] net: check payload length limit for all frames
2020-07-20 11:46 ` Li Qiang
@ 2020-07-20 12:57 ` P J P
2020-07-20 13:20 ` Li Qiang
2020-07-20 14:02 ` Alexander Bulekov
1 sibling, 1 reply; 14+ messages in thread
From: P J P @ 2020-07-20 12:57 UTC (permalink / raw)
To: Li Qiang; +Cc: Alexander Bulekov, Jason Wang, Dmitry Fleytman, QEMU Developers
+-- On Mon, 20 Jul 2020, Li Qiang wrote --+
| This seems is the same issue as LP#1886362 . Look at the free path. Here the
| 'e1000e_write_to_rx_buffers' trigger DMA and then go to address space
| dispatch. So the DMA is not RAM but a MMIO range. Then we go to another send
| path, and in that we frees the 'iov'.
Cool. Thanks so much for the confirmation Li.
| Alex do you tried my patch to solve LP#1886362 ? I have tried it and it
| seems no this UAF triggered.
He mentioned that your patch fixes both issues:
-> https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05367.html
...
> On the other hand, I cannot reproduce either issue with Li's patch:
> Message-Id: <20200716161453.61295-1-liq3ea@163.com>
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH] net: check payload length limit for all frames
2020-07-20 12:57 ` P J P
@ 2020-07-20 13:20 ` Li Qiang
0 siblings, 0 replies; 14+ messages in thread
From: Li Qiang @ 2020-07-20 13:20 UTC (permalink / raw)
To: P J P; +Cc: Alexander Bulekov, Jason Wang, Dmitry Fleytman, QEMU Developers
P J P <ppandit@redhat.com> 于2020年7月20日周一 下午8:57写道：
>
> +-- On Mon, 20 Jul 2020, Li Qiang wrote --+
> | This seems is the same issue as LP#1886362 . Look at the free path. Here the
> | 'e1000e_write_to_rx_buffers' trigger DMA and then go to address space
> | dispatch. So the DMA is not RAM but a MMIO range. Then we go to another send
> | path, and in that we frees the 'iov'.
>
> Cool. Thanks so much for the confirmation Li.
>
> | Alex do you tried my patch to solve LP#1886362 ? I have tried it and it
> | seems no this UAF triggered.
>
> He mentioned that your patch fixes both issues:
> -> https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05367.html
Ok, then let's focus that patch.
Thanks,
Li Qiang
> ...
> > On the other hand, I cannot reproduce either issue with Li's patch:
> > Message-Id: <20200716161453.61295-1-liq3ea@163.com>
>
>
> Thank you.
> --
> Prasad J Pandit / Red Hat Product Security Team
> 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] net: check payload length limit for all frames
2020-07-20 11:46 ` Li Qiang
2020-07-20 12:57 ` P J P
@ 2020-07-20 14:02 ` Alexander Bulekov
1 sibling, 0 replies; 14+ messages in thread
From: Alexander Bulekov @ 2020-07-20 14:02 UTC (permalink / raw)
To: Li Qiang; +Cc: Jason Wang, Dmitry Fleytman, QEMU Developers, P J P
On 200720 1946, Li Qiang wrote:
>
> This seems is the same issue as LP#1886362 .
> Look at the free path.
> Here the 'e1000e_write_to_rx_buffers' trigger DMA and then go to
> address space dispatch. So the DMA is not RAM but a MMIO range.
> Then we go to another send path, and in that we frees the 'iov'.
>
> Alex do you tried my patch to solve LP#1886362 ?
> I have tried it and it seems no this UAF triggered.
Hi Li,
I think the bugs are triggered in a similar way, and they stem from the
same underlying issue (the code wasn't designed to read/write to its own
MMIO range), but the actual UAFs are different.
I agree that your patch should fix all of these types of bugs in the
e1000e.
Thanks
-Alex
> Thanks,
> Li Qiang
>
>
> > previously allocated by thread T0 here:
> > #0 0x561dd231130d in malloc (/home/alxndr/Development/qemu/build-asan/i386-softmmu/qemu-system-i386+0x2bb630d)
> > #1 0x7f58c023d500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500)
> > #2 0x561dd43d0666 in net_rx_pkt_pull_data /home/alxndr/Development/qemu/hw/net/net_rx_pkt.c:103:9
> > #3 0x561dd43d2cf6 in net_rx_pkt_attach_iovec_ex /home/alxndr/Development/qemu/hw/net/net_rx_pkt.c:158:5
> > #4 0x561dd440360f in e1000e_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1695:5
> > #5 0x561dd43fd91a in e1000e_nc_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e.c:213:12
> > #6 0x561dd43c82e7 in net_tx_pkt_sendv /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:553:9
> > #7 0x561dd43c65e6 in net_tx_pkt_send /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:629:9
> > #8 0x561dd43c9c78 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:642:11
> > #9 0x561dd4472cf6 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664:16
> > #10 0x561dd446f296 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743:17
> > #11 0x561dd446ce68 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9
> > #12 0x561dd445635d in e1000e_set_tdt /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9
> > #13 0x561dd440f19e in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3265:9
> > #14 0x561dd43f77b7 in e1000e_mmio_write /home/alxndr/Development/qemu/hw/net/e1000e.c:109:5
> > #15 0x561dd2ff62a3 in memory_region_write_accessor /home/alxndr/Development/qemu/softmmu/memory.c:483:5
> > #16 0x561dd2ff5747 in access_with_adjusted_size /home/alxndr/Development/qemu/softmmu/memory.c:544:18
> > #17 0x561dd2ff3366 in memory_region_dispatch_write /home/alxndr/Development/qemu/softmmu/memory.c:1465:16
> > #18 0x561dd23a5476 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3176:23
> > #19 0x561dd238de86 in flatview_write /home/alxndr/Development/qemu/exec.c:3216:14
> > #20 0x561dd238d9a7 in address_space_write /home/alxndr/Development/qemu/exec.c:3307:18
> > #21 0x561dd30a43b1 in qtest_process_command /home/alxndr/Development/qemu/softmmu/qtest.c:567:9
> > #22 0x561dd3094b38 in qtest_process_inbuf /home/alxndr/Development/qemu/softmmu/qtest.c:710:9
> > #23 0x561dd30937c5 in qtest_read /home/alxndr/Development/qemu/softmmu/qtest.c:722:5
> > #24 0x561dd5f33993 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/chardev/char.c:188:9
> > #25 0x561dd5f33b17 in qemu_chr_be_write /home/alxndr/Development/qemu/chardev/char.c:200:9
> > #26 0x561dd5f47e03 in fd_chr_read /home/alxndr/Development/qemu/chardev/char-fd.c:68:9
> > #27 0x561dd609c1c4 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/io/channel-watch.c:84:12
> > #28 0x7f58c0237897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897)
> >
> > Let me know if I can help with anything else!
> > -Alex
> >
> > > Thank you.
> > > --
> > > Prasad J Pandit / Red Hat Product Security Team
> > > 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
> >
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-07-20 14:04 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-16 19:23 [PATCH] net: check payload length limit for all frames P J P
2020-07-17 0:53 ` Li Qiang
2020-07-17 1:21 ` Alexander Bulekov
2020-07-17 3:13 ` Jason Wang
2020-07-17 5:06 ` P J P
2020-07-17 5:51 ` Jason Wang
2020-07-17 9:08 ` P J P
2020-07-17 10:02 ` Li Qiang
2020-07-20 2:24 ` P J P
2020-07-20 3:33 ` Alexander Bulekov
2020-07-20 11:46 ` Li Qiang
2020-07-20 12:57 ` P J P
2020-07-20 13:20 ` Li Qiang
2020-07-20 14:02 ` Alexander Bulekov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.