Got a new bug with regression range ccfa9f2c1427b40483984198c3df41f8057f69f8:6dfab8cfb94ccb485a15b13df3c499cbb06fddf2
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Jul 1 2021
Jul 1 2021
Jun 29 2021
Jun 29 2021
curve=23 secp256r1 point=040000ffffffff0000000000000000000000000000000000000000000000000000cfe26d107a5134d6feb38ce3577075bdc7aa70ff7523d3b203c8a973f2d3dc8e bignum=0000000000ff0000000400000000000000000000005d00003277002000010000 mbedtls: 0 04fd351b304ad50f36153d8193c4bbf7d4c3bee26e5af52a9c70133edfa62c273e05da8312615436e9c81b5b0624e68667233ace6307afc8056eae85049ca63226 gcrypt: 0 04d6915640b8ba3918f129c108f52f571ec28c1c89ad710b43928c3bd942eb29d8bf181e997b502abf12cf3606eb46379c59fd396bda7b45cdc75d429b2b37b15f
curve=24 secp384r1 point=0400000000000000000000000000000000000000000000000000000000000000000000000000fffffffffffffffffffffc1b0d6f8fb7f2de5b8875645b64042ae20f119f3e1cfefc0215857eeae5f4a8fca737057d69a42c44d958e7cfcc77ce6b bignum=ffffffffffffffffffffffffffffffffffffffffffffffffc7634d81f4372ddf581a0db248b0a77aecec196accc52972 mbedtls: 0 0400000000000000000000000000000000000000000000000000000000000000000000000000fffffffffffffffffffffce4f29070480d21a4778a9ba49bfbd51df0ee60c1e30103fdea7a81151a0b570258c8fa81965bd3bb26a7183133883194 gcrypt: 0 04fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffeffffffff0100000000000000fffffffbe4f29070480d21a4778a9ba49bfbd51df0ee60c1e30103fdea7a81151a0b570258c8fa81965bd3bb26a7183133883194
Jun 28 2021
Jun 28 2021
Is secp192r1 only curve that is giving wrong results?
Jun 27 2021
Jun 27 2021
Jun 27 2019
Jun 27 2019
Great :-)
Jun 26 2019
Jun 26 2019
It looks like this commit breaks the build by me
May 15 2019
May 15 2019
Great :-)
This was a change (fixing file descriptor leaks in iconv.m4) that I needed to do for building fuzzing
https://github.com/google/oss-fuzz/blob/master/projects/gnupg/fuzzgnupg.diff#L178
Apr 17 2019
Apr 17 2019
Fix is ok for oss-fuzz
Apr 16 2019
Apr 16 2019
Mar 19 2019
Mar 19 2019
Running
valgrind --leak-check=full ./g10/gpg --import clusterfuzz-testcase-minimized-fuzz_import-5751600352591872.dms
gave me at commit f799e9728bcadb3d4148a47848c78c5647860ea4
==11882== 232 (16 direct, 216 indirect) bytes in 1 blocks are definitely lost in loss record 290 of 333 ==11882== at 0x1001C32C5: malloc (vg_replace_malloc.c:302) ==11882== by 0x100B211B9: do_malloc (in /usr/local/Cellar/libgcrypt/1.8.3/lib/libgcrypt.20.dylib) ==11882== by 0x100B214D5: _gcry_xmalloc (in /usr/local/Cellar/libgcrypt/1.8.3/lib/libgcrypt.20.dylib) ==11882== by 0x100058A1D: read_block (import.c:929) ==11882== by 0x10005B772: import (import.c:584) ==11882== by 0x1000597FF: import_keys_internal (import.c:486) ==11882== by 0x1000596FE: import_keys (import.c:526) ==11882== by 0x10000727B: main (gpg.c:4675)
Mar 18 2019
Mar 18 2019
Ok, I will wait longer next time.
How do I make the file accessible ? (I can download it)
clusterfuzz-testcase-minimized-fuzz_import-5751600352591872.dms186 BDownload
Mar 15 2019
Mar 15 2019
Nov 28 2018
Nov 28 2018
@gniibe there seems to be one remaining issue.
Even with iobuf_get_noeof, we have to cast to an unsigned integer before shifting 24 places to avoid undefined behavior :
diff --git a/common/iobuf.c b/common/iobuf.c index 5eeba8fe6..1b9722d0a 100644 --- a/common/iobuf.c +++ b/common/iobuf.c @@ -878,7 +878,7 @@ block_filter (void *opaque, int control, iobuf_t chain, byte * buffer, } else if (c == 255) { - a->size = iobuf_get_noeof (chain) << 24; + a->size = (size_t)iobuf_get_noeof (chain) << 24; a->size |= iobuf_get_noeof (chain) << 16; a->size |= iobuf_get_noeof (chain) << 8; if ((c = iobuf_get (chain)) == -1) ``
Sep 12 2018
Sep 12 2018
Sep 10 2018
Sep 10 2018
Aug 7 2018
Aug 7 2018
There is the same bug and fix in function parse_key :
diff --git a/g10/parse-packet.c b/g10/parse-packet.c index 0d28e7ac1..b147179e2 100644 --- a/g10/parse-packet.c +++ b/g10/parse-packet.c @@ -2533,7 +2533,7 @@ parse_key (IOBUF inp, int pkttype, unsigned long pktlen, err = gpg_error (GPG_ERR_INV_PACKET); goto leave; } - ski->s2k.count = iobuf_get (inp); + ski->s2k.count = iobuf_get_noeof (inp); pktlen--; if (list_mode) es_fprintf (listfp, "\tprotect count: %lu (%lu)\n",
Aug 6 2018
Aug 6 2018
Jun 30 2018
Jun 30 2018
May 3 2018
May 3 2018
Ok, so I guess that you can close this ticket.
Apr 27 2018
Apr 27 2018
I now have all three fuzz targets stable now, and not finding more bugs besides the reported memory leaks
https://github.com/gpg/gnupg/compare/master...catenacyber:7651c60
What do you think of it ? Do you want to use it for continuous integration ?
Apr 23 2018
Apr 23 2018
Apr 19 2018
Apr 19 2018
Work is in progress, but you can already see :
- some independent changes to the build system https://github.com/gpg/gnupg/compare/master...catenacyber:fdf1ec2
- adding the code for fuzz targets and build them https://github.com/gpg/gnupg/compare/fdf1ec2...catenacyber:fd62943
- changes to gnupg code to go beyond first bugs detected https://github.com/gpg/gnupg/compare/fd62943...catenacyber:3c14d0d
Apr 18 2018
Apr 18 2018
You may want to check with Hanno Böck
Apr 17 2018
Apr 17 2018
Sorry myself.
I will try to be clearer :
Ok, thanks for the reply
With this example, the problem happens at
a->size |= iobuf_get (chain) << 8;
iobuf_get (chain)returns -1 and -1 << 8 is not well defined.
Apr 14 2018
Apr 14 2018
You are welcome :-) I did not know about that 39-Arigato
Apr 13 2018
Apr 13 2018
Apr 12 2018
Apr 12 2018
leak-a702b3e5612e12163f056f41feb9e95a8b3836bb809 BDownload
Bug can be reproduced with gpg --verify leak-a702b3e5612e12163f056f41feb9e95a8b3836bb