From 09f2a7bca624d0492e1d7ab29ce19542249c13ff Mon Sep 17 00:00:00 2001 From: "Neal H. Walfield" Date: Fri, 21 Aug 2015 11:55:15 +0200 Subject: common: Don't incorrectly reject 4 GB - 1 sized packets. * g10/parse-packet.c (parse): Don't reject 4 GB - 1 sized packets. Add the constraint that the type must be 63. * kbx/keybox-openpgp.c (next_packet): Likewise. * tests/openpgp/4gb-packet.asc: New file. * tests/openpgp/4gb-packet.test: New file. * tests/openpgp/Makefile.am (TESTS): Add 4gb-packet.test. (TEST_FILES): Add 4gb-packet.asc. -- Signed-off-by: Neal H. Walfield . --- g10/parse-packet.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'g10/parse-packet.c') diff --git a/g10/parse-packet.c b/g10/parse-packet.c index bc9965331..edebbe782 100644 --- a/g10/parse-packet.c +++ b/g10/parse-packet.c @@ -643,7 +643,14 @@ parse (IOBUF inp, PACKET * pkt, int onlykeypkts, off_t * retpos, } } - if (pktlen == (unsigned long) (-1)) + /* Sometimes the decompressing layer enters an error state in which + it simply outputs 0xff for every byte read. If we have a stream + of 0xff bytes, then it will be detected as a new format packet + with type 63 and a 4-byte encoded length that is 4G-1. Since + packets with type 63 are private and we use them as a control + packet, which won't be 4 GB, we reject such packets as + invalid. */ + if (pkttype == 63 && pktlen == 0xFFFFFFFF) { /* With some probability this is caused by a problem in the * the uncompressing layer - in some error cases it just loops -- cgit v1.2.3