security-and-privacy/gnupg
security-and-privacy/gnupg
1
0
Fork 0
mirror of git://git.gnupg.org/gnupg.git synced 2025-07-03 22:56:33 +02:00
Code Activity

common: Don't incorrectly reject 4 GB - 1 sized packets.

Browse source 
* 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 <neal@g10code.com>.
This commit is contained in:
Neal H. Walfield 2015-08-21 11:55:15 +02:00
parent 4f37820334
commit 09f2a7bca6
5 changed files with 34 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

9
g10/parse-packet.c
View file

@ -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