From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: slirp@lists.freedesktop.org
Cc: "Petr Matousek" <pmatouse@redhat.com>,
"Vishnu Dev TJ" <vishnudevtj@gmail.com>,
qemu-stable@nongnu.org, qemu-devel@nongnu.org,
"Prasad J Pandit" <ppandit@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: [Qemu-devel] [PATCH 1/2] Do not reassemble fragments pointing outside of the original payload
Date: Thu, 22 Aug 2019 16:41:33 +0200 [thread overview]
Message-ID: <20190822144134.23521-2-philmd@redhat.com> (raw)
In-Reply-To: <20190822144134.23521-1-philmd@redhat.com>
The vulnerability CVE-2019-14378 is well explained in [1]:
The bug is triggered when large IPv4 fragmented packets are
reassembled for processing.
For the NAT translation if the incoming packets are fragmented
they should be reassembled before they are edited and
re-transmitted.
This reassembly is done by the
ip_reass(Slirp *slirp, struct ip *ip, struct ipq *fp) function.
ip contains the current IP packet data, fp is a link list
containing the fragmented packets.
ip_reass() does the following:
* If first fragment to arrive (fp==NULL), create a reassembly
queue and insert ip into this queue.
* Check if the fragment is overlapping with previous received
fragments, then discard it.
* If all the fragmented packets are received reassemble it.
Create header for new ip packet by modifying header of first
packet.
The bug is at the calculation of the variable delta. The code
assumes that the first fragmented packet will not be allocated in
the external buffer (m_ext). The calculation q - m->dat is valid
when the packet data is inside mbuf->m_dat (q will be inside m_dat)
(q is structure containing link list of fragments and packet data).
Otherwise if m_ext buffer was allocated, then q will be inside the
external buffer and the calculation of the delta will be wrong.
Later the newly calculated pointer q is converted into ip structure
and values are modified, Due to the wrong calculation of the delta,
ip will be pointing to incorrect location and ip_src and ip_dst can
be used to write controlled data onto the calculated location. This
may also crash qemu if the calculated ip is located in unmaped area.
Do not queue fragments pointing out of the original payload to avoid
to calculate the variable delta.
[1] https://vishnudevtj.github.io/notes/qemu-vm-escape-cve-2019-14378
Fixes: CVE-2019-14378
Reported-by: Vishnu Dev TJ <vishnudevtj@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
src/ip_input.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/ip_input.c b/src/ip_input.c
index 7364ce0..ee52085 100644
--- a/src/ip_input.c
+++ b/src/ip_input.c
@@ -304,6 +304,19 @@ static struct ip *ip_reass(Slirp *slirp, struct ip *ip, struct ipq *fp)
ip_deq(q->ipf_prev);
}
+ /*
+ * If we received the first fragment, we know the original
+ * payload size. Verify fragments are within our payload.
+ */
+ for (q = fp->frag_link.next; q != (struct ipasfrag*)&fp->frag_link;
+ q = q->ipf_next) {
+ if (!q->ipf_off && q->ipf_len) {
+ if (ip->ip_off + ip->ip_len >= q->ipf_len) {
+ goto dropfrag;
+ }
+ }
+ }
+
insert:
/*
* Stick new segment in its place;
--
2.20.1
next prev parent reply other threads:[~2019-08-22 14:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 14:41 [Qemu-devel] [PATCH 0/2] slirp: Fix heap buffer overflow during packet reassembly (CVE-2019-14378) Philippe Mathieu-Daudé
2019-08-22 14:41 ` Philippe Mathieu-Daudé [this message]
2019-08-22 18:33 ` [Qemu-devel] [Slirp] [PATCH 1/2] Do not reassemble fragments pointing outside of the original payload Samuel Thibault
2019-08-23 15:15 ` Philippe Mathieu-Daudé
2019-08-25 22:54 ` Samuel Thibault
2019-08-29 11:13 ` P J P
2019-08-29 15:43 ` Philippe Mathieu-Daudé
2019-08-29 15:53 ` Philippe Mathieu-Daudé
2019-08-29 16:00 ` Philippe Mathieu-Daudé
2019-08-22 14:41 ` [Qemu-devel] [RFC PATCH 2/2] Delay crash when mbufs are corrupted Philippe Mathieu-Daudé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190822144134.23521-2-philmd@redhat.com \
--to=philmd@redhat.com \
--cc=pmatouse@redhat.com \
--cc=ppandit@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=slirp@lists.freedesktop.org \
--cc=vishnudevtj@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).