Bug#990748: Proposed patch/debdiff
Control: tags 990748 + patch
Control: tags 990749 + patch
Hi
Attached is the current proposed debdiff (not yet uploaded).
Regards,
Salvatore
diff -Nru linuxptp-3.1/debian/changelog linuxptp-3.1/debian/changelog
--- linuxptp-3.1/debian/changelog 2020-12-13 23:33:39.000000000 +0100
+++ linuxptp-3.1/debian/changelog 2021-07-06 20:16:00.000000000 +0200
@@ -1,3 +1,13 @@
+linuxptp (3.1-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Validate the messageLength field of incoming messages (CVE-2021-3570)
+ (Closes: #990748)
+ * tc: Fix length of follow-up message of one-step sync (CVE-2021-3571)
+ (Closes: #990749)
+
+ -- Salvatore Bonaccorso <carnil@debian.org> Tue, 06 Jul 2021 20:16:00 +0200
+
linuxptp (3.1-2) unstable; urgency=medium
[ Punit Agrawal ]
diff -Nru linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch
--- linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch 1970-01-01 01:00:00.000000000 +0100
+++ linuxptp-3.1/debian/patches/Validate-the-messageLength-field-of-incoming-message.patch 2021-07-06 20:11:54.000000000 +0200
@@ -0,0 +1,96 @@
+From: Richard Cochran <richardcochran@gmail.com>
+Date: Sat, 17 Apr 2021 15:15:18 -0700
+Subject: Validate the messageLength field of incoming messages.
+Origin: https://github.com/richardcochran/linuxptp/commit/ce15e4de5926724557e8642ec762a210632f15ca
+Bug-Debian: https://bugs.debian.org/990748
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-3570
+
+The PTP messageLength field is redundant because the length of a PTP
+message is precisely determined by the message type and the appended
+TLVs. The current implementation validates the sizes of both the main
+message (according to the fixed header length and fixed length by
+type) and the TLVs (by using the 'L' of the TLV).
+
+However, when forwarding a message, the messageLength field is used.
+If a message arrives with a messageLength field larger than the actual
+message size, the code will read and possibly write data beyond the
+allocated buffer.
+
+Fix the issue by validating the field on ingress. This prevents
+reading and sending data past the message buffer when forwarding a
+management message or other messages when operating as a transparent
+clock, and it also prevents a memory corruption in msg_post_recv()
+after forwarding a management message.
+
+Reported-by: Miroslav Lichvar <mlichvar@redhat.com>
+Signed-off-by: Richard Cochran <richardcochran@gmail.com>
+---
+ msg.c | 18 ++++++++++++------
+ 1 file changed, 12 insertions(+), 6 deletions(-)
+
+diff --git a/msg.c b/msg.c
+index d1619d4973f1..5ae8ebbfc3ae 100644
+--- a/msg.c
++++ b/msg.c
+@@ -186,7 +186,7 @@ static int suffix_post_recv(struct ptp_message *msg, int len)
+ {
+ uint8_t *ptr = msg_suffix(msg);
+ struct tlv_extra *extra;
+- int err;
++ int err, suffix_len = 0;
+
+ if (!ptr)
+ return 0;
+@@ -204,12 +204,14 @@ static int suffix_post_recv(struct ptp_message *msg, int len)
+ tlv_extra_recycle(extra);
+ return -EBADMSG;
+ }
++ suffix_len += sizeof(struct TLV);
+ len -= sizeof(struct TLV);
+ ptr += sizeof(struct TLV);
+ if (extra->tlv->length > len) {
+ tlv_extra_recycle(extra);
+ return -EBADMSG;
+ }
++ suffix_len += extra->tlv->length;
+ len -= extra->tlv->length;
+ ptr += extra->tlv->length;
+ err = tlv_post_recv(extra);
+@@ -219,7 +221,7 @@ static int suffix_post_recv(struct ptp_message *msg, int len)
+ }
+ msg_tlv_attach(msg, extra);
+ }
+- return 0;
++ return suffix_len;
+ }
+
+ static void suffix_pre_send(struct ptp_message *msg)
+@@ -337,7 +339,7 @@ void msg_get(struct ptp_message *m)
+
+ int msg_post_recv(struct ptp_message *m, int cnt)
+ {
+- int pdulen, type, err;
++ int err, pdulen, suffix_len, type;
+
+ if (cnt < sizeof(struct ptp_header))
+ return -EBADMSG;
+@@ -422,9 +424,13 @@ int msg_post_recv(struct ptp_message *m, int cnt)
+ break;
+ }
+
+- err = suffix_post_recv(m, cnt - pdulen);
+- if (err)
+- return err;
++ suffix_len = suffix_post_recv(m, cnt - pdulen);
++ if (suffix_len < 0) {
++ return suffix_len;
++ }
++ if (pdulen + suffix_len != m->header.messageLength) {
++ return -EBADMSG;
++ }
+
+ return 0;
+ }
+--
+2.32.0
+
diff -Nru linuxptp-3.1/debian/patches/series linuxptp-3.1/debian/patches/series
--- linuxptp-3.1/debian/patches/series 1970-01-01 01:00:00.000000000 +0100
+++ linuxptp-3.1/debian/patches/series 2021-07-06 20:14:15.000000000 +0200
@@ -0,0 +1,2 @@
+Validate-the-messageLength-field-of-incoming-message.patch
+tc-Fix-length-of-follow-up-message-of-one-step-sync.patch
diff -Nru linuxptp-3.1/debian/patches/tc-Fix-length-of-follow-up-message-of-one-step-sync.patch linuxptp-3.1/debian/patches/tc-Fix-length-of-follow-up-message-of-one-step-sync.patch
--- linuxptp-3.1/debian/patches/tc-Fix-length-of-follow-up-message-of-one-step-sync.patch 1970-01-01 01:00:00.000000000 +0100
+++ linuxptp-3.1/debian/patches/tc-Fix-length-of-follow-up-message-of-one-step-sync.patch 2021-07-06 20:12:23.000000000 +0200
@@ -0,0 +1,31 @@
+From: Miroslav Lichvar <mlichvar@redhat.com>
+Date: Fri, 26 Mar 2021 09:57:43 +0100
+Subject: tc: Fix length of follow-up message of one-step sync.
+Origin: https://github.com/richardcochran/linuxptp/commit/0b3ab45de6a96ca181a5cf62c3c2b97167e2ed20
+Bug-Debian: https://bugs.debian.org/990749
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-3571
+
+Convert the length of the generated follow-up message to network order.
+This fixes reading and sending of data past the message buffer.
+
+Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
+---
+ tc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tc.c b/tc.c
+index fb466031a7ca..0346ba969e17 100644
+--- a/tc.c
++++ b/tc.c
+@@ -452,7 +452,7 @@ int tc_fwd_sync(struct port *q, struct ptp_message *msg)
+ }
+ fup->header.tsmt = FOLLOW_UP | (msg->header.tsmt & 0xf0);
+ fup->header.ver = msg->header.ver;
+- fup->header.messageLength = sizeof(struct follow_up_msg);
++ fup->header.messageLength = htons(sizeof(struct follow_up_msg));
+ fup->header.domainNumber = msg->header.domainNumber;
+ fup->header.sourcePortIdentity = msg->header.sourcePortIdentity;
+ fup->header.sequenceId = msg->header.sequenceId;
+--
+2.32.0
+
Reply to: