From dbaryshkov at gmail.com  Wed May  6 21:02:03 2020
From: dbaryshkov at gmail.com (Dmitry Baryshkov)
Date: Wed,  6 May 2020 22:02:03 +0300
Subject: [PATCH 1/2] mpicalc: fix typo
Message-ID: <20200506190204.2070413-1-dbaryshkov@gmail.com>

From: Dmitry Eremin-Solenikov <dbaryshkov at gmail.com>

* src/mpicalc.c (print_help): fix typo in commands description.

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov at gmail.com>
---
 src/mpicalc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mpicalc.c b/src/mpicalc.c
index 11246f380f11..0903e0a4d397 100644
--- a/src/mpicalc.c
+++ b/src/mpicalc.c
@@ -313,7 +313,7 @@ print_help (void)
   fputs ("+   add           [0] := [1] + [0]          {-1}\n"
          "-   subtract      [0] := [1] - [0]          {-1}\n"
          "*   multiply      [0] := [1] * [0]          {-1}\n"
-         "/   divide        [0] := [1] - [0]          {-1}\n"
+         "/   divide        [0] := [1] / [0]          {-1}\n"
          "%   modulo        [0] := [1] % [0]          {-1}\n"
          "<   left shift    [0] := [0] << 1           {0}\n"
          ">   right shift   [0] := [0] >> 1           {0}\n"
-- 
2.26.2



From dbaryshkov at gmail.com  Wed May  6 21:02:04 2020
From: dbaryshkov at gmail.com (Dmitry Baryshkov)
Date: Wed,  6 May 2020 22:02:04 +0300
Subject: [PATCH 2/2] tests/benchmark.c: fix error message for invalid MAC algo
In-Reply-To: <20200506190204.2070413-1-dbaryshkov@gmail.com>
References: <20200506190204.2070413-1-dbaryshkov@gmail.com>
Message-ID: <20200506190204.2070413-2-dbaryshkov@gmail.com>

From: Dmitry Eremin-Solenikov <dbaryshkov at gmail.com>

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov at gmail.com>
---
 tests/benchmark.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/benchmark.c b/tests/benchmark.c
index a245152c0228..5963527e1d7a 100644
--- a/tests/benchmark.c
+++ b/tests/benchmark.c
@@ -613,7 +613,7 @@ mac_bench ( const char *algoname )
   algo = gcry_mac_map_name (algoname);
   if (!algo)
     {
-      fprintf (stderr, PGM ": invalid hash algorithm `%s'\n", algoname);
+      fprintf (stderr, PGM ": invalid MAC algorithm `%s'\n", algoname);
       exit (1);
     }
 
-- 
2.26.2



From wk at gnupg.org  Wed May  6 21:06:53 2020
From: wk at gnupg.org (Werner Koch)
Date: Wed, 06 May 2020 21:06:53 +0200
Subject: [PATCH] tests/benchmark.c: fix error message for invalid MAC algo
In-Reply-To: <20200320134928.2231683-1-dbaryshkov@gmail.com> (Dmitry
 Eremin-Solenikov via Gcrypt-devel's message of "Fri, 20 Mar 2020
 16:49:28 +0300")
References: <20200320134928.2231683-1-dbaryshkov@gmail.com>
Message-ID: <87v9l8vq5u.fsf@wheatstone.g10code.de>

Hi!

Applied.  Thanks.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Wed May  6 21:08:20 2020
From: wk at gnupg.org (Werner Koch)
Date: Wed, 06 May 2020 21:08:20 +0200
Subject: [PATCH v2] mpi: Fix error that point not uninitialized
In-Reply-To: <20200108133649.2375-1-tianjia.zhang@linux.alibaba.com> (Tianjia
 Zhang via Gcrypt-devel's message of "Wed,
 8 Jan 2020 21:36:49 +0800")
References: <20200108133649.2375-1-tianjia.zhang@linux.alibaba.com>
Message-ID: <87o8r0vq3f.fsf@wheatstone.g10code.de>

On Wed,  8 Jan 2020 21:36, Tianjia Zhang said:
> * cipher/ecc-curves.c (mpi_ec_get_elliptic_curve): Initialize E->G poing

Do you have a bug report for this or how did you stepped on this?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20200506/78c5c6a1/attachment.sig>

From tianjia.zhang at linux.alibaba.com  Thu May  7 04:34:34 2020
From: tianjia.zhang at linux.alibaba.com (Tianjia Zhang)
Date: Thu, 7 May 2020 10:34:34 +0800
Subject: [PATCH v2] mpi: Fix error that point not uninitialized
In-Reply-To: <87o8r0vq3f.fsf@wheatstone.g10code.de>
References: <20200108133649.2375-1-tianjia.zhang@linux.alibaba.com>
 <87o8r0vq3f.fsf@wheatstone.g10code.de>
Message-ID: <e2eef778-df27-ada7-9dd7-3111ba042f89@linux.alibaba.com>



On 2020/5/7 3:08, Werner Koch wrote:
> On Wed,  8 Jan 2020 21:36, Tianjia Zhang said:
>> * cipher/ecc-curves.c (mpi_ec_get_elliptic_curve): Initialize E->G poing
> 
> Do you have a bug report for this or how did you stepped on this?
> 
> 
> Shalom-Salam,
> 
>     Werner
> 

This was discovered when I developed the sm2 algorithm before. Calling 
_gcry_mpi_ec_internal_new() to generate an ec from ecc_domain_parms_t 
will cause a crash. It seems that there is no such usage in the existing 
code. For details, please refer to the earliest patch of sm2, Of course, 
this patch is not accepted.

https://lists.gnupg.org/pipermail/gcrypt-devel/2019-December/004862.html

Thanks and best,
Tianjia


From guidovranken at gmail.com  Fri May  8 00:24:03 2020
From: guidovranken at gmail.com (Guido Vranken)
Date: Fri, 8 May 2020 00:24:03 +0200
Subject: gcry_mpi_invm succeeds if the inverse does not exist
In-Reply-To: <87zhbeh921.fsf@iwagami.gniibe.org>
References: <CAO5O-ELb_27vpXnAXeeJZxnovftEqe_aFe0JsbUs7KMhtEuD=Q@mail.gmail.com>
 <87zhbeh921.fsf@iwagami.gniibe.org>
Message-ID: <CAO5O-EJipQu2VBbtTiO_bt=7mJ35aT_AFd-OJz4F9swR7SfWbg@mail.gmail.com>

I'm running my crypto library fuzzer on Google OSS-Fuzz and it keeps
finding bugs in gcry_mpi_invm.

jussi kivilinna receives these reports. Would you mind taking a look?

On Tue, Apr 14, 2020 at 8:32 AM NIIBE Yutaka <gniibe at fsij.org> wrote:

> Hello,
>
> Thank you for your report with a test case.  It helps a lot.
>
> Guido Vranken wrote:
> > This is not in accordance with the documentation:
> >
> > Function: int gcry_mpi_invm (gcry_mpi_t x, gcry_mpi_t a, gcry_mpi_t m)
> > Set x to the multiplicative inverse of a \bmod m. Return true if the
> > inverse exists.
>
> Indeed.  It seems that API was changed to return the result
> (success/failure) in libgcrypt 1.3.2 in 2007.  Before that, the API was
> void (no return value).  Since the initial change, it never returns
> correct value.
>
> I'll fix for 1.9.
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20200508/85e78542/attachment.html>

From jussi.kivilinna at iki.fi  Fri May  8 18:16:34 2020
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Fri, 8 May 2020 19:16:34 +0300
Subject: gcry_mpi_invm succeeds if the inverse does not exist
In-Reply-To: <CAO5O-EJipQu2VBbtTiO_bt=7mJ35aT_AFd-OJz4F9swR7SfWbg@mail.gmail.com>
References: <CAO5O-ELb_27vpXnAXeeJZxnovftEqe_aFe0JsbUs7KMhtEuD=Q@mail.gmail.com>
 <87zhbeh921.fsf@iwagami.gniibe.org>
 <CAO5O-EJipQu2VBbtTiO_bt=7mJ35aT_AFd-OJz4F9swR7SfWbg@mail.gmail.com>
Message-ID: <51fc5b09-7b2f-ce2e-bb8c-f653ba907446@iki.fi>

Hello,

On 8.5.2020 1.24, Guido Vranken via Gcrypt-devel wrote:
> I'm running my crypto library fuzzer on Google OSS-Fuzz and it keeps finding bugs in gcry_mpi_invm.
> 
> jussi kivilinna receives these reports. Would you mind taking a look?

I did see "Issue 21708 in oss-fuzz: cryptofuzz:cryptofuzz-openssl: ASSERT: Botan-libgcrypt-BignumCalc-(no algorithm)-difference" 2020-04-15 and follow-up discussion and that resulted bug-report to this mailing list. I have not seen any further reports from OSS-Fuzz. 

If this keeps causing too much noise as repeated bug reports, cannot you disable the BigNum fuzzing of libgcrypt until this gets fixed?

-Jussi

> 
> On Tue, Apr 14, 2020 at 8:32 AM NIIBE Yutaka <gniibe at fsij.org <mailto:gniibe at fsij.org>> wrote:
> 
>     Hello,
> 
>     Thank you for your report with a test case.? It helps a lot.
> 
>     Guido Vranken wrote:
>     > This is not in accordance with the documentation:
>     >
>     > Function: int gcry_mpi_invm (gcry_mpi_t x, gcry_mpi_t a, gcry_mpi_t m)
>     > Set x to the multiplicative inverse of a \bmod m. Return true if the
>     > inverse exists.
> 
>     Indeed.? It seems that API was changed to return the result
>     (success/failure) in libgcrypt 1.3.2 in 2007.? Before that, the API was
>     void (no return value).? Since the initial change, it never returns
>     correct value.
> 
>     I'll fix for 1.9.
>     -- 
> 
> 
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> 



From guidovranken at gmail.com  Sat May  9 13:14:04 2020
From: guidovranken at gmail.com (Guido Vranken)
Date: Sat, 9 May 2020 13:14:04 +0200
Subject: gcry_mpi_invm succeeds if the inverse does not exist
In-Reply-To: <51fc5b09-7b2f-ce2e-bb8c-f653ba907446@iki.fi>
References: <CAO5O-ELb_27vpXnAXeeJZxnovftEqe_aFe0JsbUs7KMhtEuD=Q@mail.gmail.com>
 <87zhbeh921.fsf@iwagami.gniibe.org>
 <CAO5O-EJipQu2VBbtTiO_bt=7mJ35aT_AFd-OJz4F9swR7SfWbg@mail.gmail.com>
 <51fc5b09-7b2f-ce2e-bb8c-f653ba907446@iki.fi>
Message-ID: <CAO5O-EJwyViAdfUY-hnZ0hgBYWkLR7DK9M2-RGvbyT-t-BEsPg@mail.gmail.com>

Here is a reproducer for the bugs. OOB reads and writes on i386:

#include <gcrypt.h>

#define CF_CHECK_EQ(expr, res) if ( (expr) != (res) ) { goto end; }

int main(void)
{
    gcry_mpi_t A;
    gcry_mpi_t B;
    gcry_mpi_t C;
    gcry_error_t err;

    CF_CHECK_EQ(err = gcry_mpi_scan(&A, GCRYMPI_FMT_HEX,
"2acc66c62cac3db610ce038e38e391", 0, NULL), 0);
    CF_CHECK_EQ(err = gcry_mpi_scan(&B, GCRYMPI_FMT_HEX,
"4105f5daf47e2dee608c82bbc02a7e5f4f1e6b205e2d099643ad0101ebd11fd3f1182bda60f00000000",
0, NULL), 0);
    CF_CHECK_EQ(err = gcry_mpi_scan(&C, GCRYMPI_FMT_HEX, "1", 0, NULL), 0);
    CF_CHECK_EQ(gcry_mpi_invm(C, A, B), 1);
    printf("Inverse exists\n");
end:

    return 0;
}

Valgrind:

==18960== Invalid read of size 4
==18960==    at 0x1875C0: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==  Address 0x4a512d4 is 0 bytes after a block of size 4 alloc&apos;d
==18960==    at 0x483021B: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==18960==    by 0x118755: _gcry_private_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x112692: do_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x112711: _gcry_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x112B50: _gcry_xmalloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x18E35C: _gcry_mpi_alloc_limb_space (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x18753B: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==
==18960== Invalid write of size 4
==18960==    at 0x1875E0: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==  Address 0x4a512d4 is 0 bytes after a block of size 4 alloc&apos;d
==18960==    at 0x483021B: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==18960==    by 0x118755: _gcry_private_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x112692: do_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x112711: _gcry_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x112B50: _gcry_xmalloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x18E35C: _gcry_mpi_alloc_limb_space (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x18753B: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==
==18960== Invalid read of size 4
==18960==    at 0x187740: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==  Address 0x4a51344 is 0 bytes after a block of size 4 alloc&apos;d
==18960==    at 0x483021B: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==18960==    by 0x118755: _gcry_private_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x112692: do_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x112711: _gcry_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x112B50: _gcry_xmalloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x18E35C: _gcry_mpi_alloc_limb_space (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x187646: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==
==18960== Invalid write of size 4
==18960==    at 0x187760: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==  Address 0x4a51344 is 0 bytes after a block of size 4 alloc&apos;d
==18960==    at 0x483021B: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==18960==    by 0x118755: _gcry_private_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x112692: do_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x112711: _gcry_malloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x112B50: _gcry_xmalloc (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x18E35C: _gcry_mpi_alloc_limb_space (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x187646: mpih_invm_pow2 (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x187F38: _gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10D9C4: gcry_mpi_invm (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)
==18960==    by 0x10CBA7: main (in
/mnt/2tb/libgcrypt-tmp/libgcrypt/21875/a.out)


On Fri, May 8, 2020 at 6:16 PM Jussi Kivilinna <jussi.kivilinna at iki.fi>
wrote:

> Hello,
>
> On 8.5.2020 1.24, Guido Vranken via Gcrypt-devel wrote:
> > I'm running my crypto library fuzzer on Google OSS-Fuzz and it keeps
> finding bugs in gcry_mpi_invm.
> >
> > jussi kivilinna receives these reports. Would you mind taking a look?
>
> I did see "Issue 21708 in oss-fuzz: cryptofuzz:cryptofuzz-openssl: ASSERT:
> Botan-libgcrypt-BignumCalc-(no algorithm)-difference" 2020-04-15 and
> follow-up discussion and that resulted bug-report to this mailing list. I
> have not seen any further reports from OSS-Fuzz.
>
> If this keeps causing too much noise as repeated bug reports, cannot you
> disable the BigNum fuzzing of libgcrypt until this gets fixed?
>
> -Jussi
>
> >
> > On Tue, Apr 14, 2020 at 8:32 AM NIIBE Yutaka <gniibe at fsij.org <mailto:
> gniibe at fsij.org>> wrote:
> >
> >     Hello,
> >
> >     Thank you for your report with a test case.  It helps a lot.
> >
> >     Guido Vranken wrote:
> >     > This is not in accordance with the documentation:
> >     >
> >     > Function: int gcry_mpi_invm (gcry_mpi_t x, gcry_mpi_t a,
> gcry_mpi_t m)
> >     > Set x to the multiplicative inverse of a \bmod m. Return true if
> the
> >     > inverse exists.
> >
> >     Indeed.  It seems that API was changed to return the result
> >     (success/failure) in libgcrypt 1.3.2 in 2007.  Before that, the API
> was
> >     void (no return value).  Since the initial change, it never returns
> >     correct value.
> >
> >     I'll fix for 1.9.
> >     --
> >
> >
> > _______________________________________________
> > Gcrypt-devel mailing list
> > Gcrypt-devel at gnupg.org
> > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> >
>
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20200509/ebf7c265/attachment-0001.html>

From gniibe at fsij.org  Wed May 13 08:44:12 2020
From: gniibe at fsij.org (Niibe Yutaka)
Date: Wed, 13 May 2020 15:44:12 +0900
Subject: gcry_mpi_invm succeeds if the inverse does not exist
In-Reply-To: <CAO5O-EJwyViAdfUY-hnZ0hgBYWkLR7DK9M2-RGvbyT-t-BEsPg@mail.gmail.com>
References: <CAO5O-ELb_27vpXnAXeeJZxnovftEqe_aFe0JsbUs7KMhtEuD=Q@mail.gmail.com>
 <87zhbeh921.fsf@iwagami.gniibe.org>
 <CAO5O-EJipQu2VBbtTiO_bt=7mJ35aT_AFd-OJz4F9swR7SfWbg@mail.gmail.com>
 <51fc5b09-7b2f-ce2e-bb8c-f653ba907446@iki.fi>
 <CAO5O-EJwyViAdfUY-hnZ0hgBYWkLR7DK9M2-RGvbyT-t-BEsPg@mail.gmail.com>
Message-ID: <87tv0k9vwj.fsf@jumper.gniibe.org>

Guido Vranken via Gcrypt-devel wrote:
> Here is a reproducer for the bugs. OOB reads and writes on i386:

Thanks.  It was me who embugged.  It was just fixed by the commit:

	69b55f87053ce2494cd4b38dc600f867bc4355be

By the way, the problem in your original report was also fixed.
Now, it should return correct value (if inverse exists or not).
-- 


From jussi.kivilinna at iki.fi  Fri May 29 21:47:08 2020
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Fri, 29 May 2020 22:47:08 +0300
Subject: [PATCH] cipher-ocb: fix out-of-array stack memory access
Message-ID: <20200529194708.1649341-1-jussi.kivilinna@iki.fi>

* cipher/cipher-ocb.c (bit_copy): Do not access memory beyond
's' array when bitoff > 8.
--

Signed-off-by: Jussi Kivilinna <jussi.kivilinna at iki.fi>
---
 cipher/cipher-ocb.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/cipher/cipher-ocb.c b/cipher/cipher-ocb.c
index b146d058..24db6a9e 100644
--- a/cipher/cipher-ocb.c
+++ b/cipher/cipher-ocb.c
@@ -67,18 +67,19 @@ double_block (u64 b[2])
 /* Copy OCB_BLOCK_LEN from buffer S starting at bit offset BITOFF to
  * buffer D.  */
 static void
-bit_copy (unsigned char *d, const unsigned char *s, unsigned int bitoff)
+bit_copy (unsigned char d[16], const unsigned char s[24], unsigned int bitoff)
 {
   u64 s0l, s1l, s1r, s2r;
   unsigned int shift;
+  unsigned int byteoff;
 
-  s += bitoff / 8;
+  byteoff = bitoff / 8;
   shift = bitoff % 8;
 
-  s0l = buf_get_be64 (s + 0);
-  s1l = buf_get_be64 (s + 8);
+  s0l = buf_get_be64 (s + byteoff + 0);
+  s1l = buf_get_be64 (s + byteoff + 8);
   s1r = shift ? s1l : 0;
-  s2r = shift ? buf_get_be64 (s + 16) : 0;
+  s2r = shift ? buf_get_be64 (s + 16) << (8 * byteoff) : 0;
 
   buf_put_be64 (d + 0, (s0l << shift) | (s1r >> ((64 - shift) & 63)));
   buf_put_be64 (d + 8, (s1l << shift) | (s2r >> ((64 - shift) & 63)));
-- 
2.25.1



From jussi.kivilinna at iki.fi  Fri May 29 21:59:51 2020
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Fri, 29 May 2020 22:59:51 +0300
Subject: gcry_mpi_invm succeeds if the inverse does not exist
In-Reply-To: <87tv0k9vwj.fsf@jumper.gniibe.org>
References: <CAO5O-ELb_27vpXnAXeeJZxnovftEqe_aFe0JsbUs7KMhtEuD=Q@mail.gmail.com>
 <87zhbeh921.fsf@iwagami.gniibe.org>
 <CAO5O-EJipQu2VBbtTiO_bt=7mJ35aT_AFd-OJz4F9swR7SfWbg@mail.gmail.com>
 <51fc5b09-7b2f-ce2e-bb8c-f653ba907446@iki.fi>
 <CAO5O-EJwyViAdfUY-hnZ0hgBYWkLR7DK9M2-RGvbyT-t-BEsPg@mail.gmail.com>
 <87tv0k9vwj.fsf@jumper.gniibe.org>
Message-ID: <6f38bc98-85fe-12b1-9cce-8e96e699e378@iki.fi>

Hello,

Cryptofuzz is reporting another heap-buffer-overflow issue in
_gcry_mpi_invm. I've attached reproducer, original from Guido and
as patch applied to tests/basic.c.

Here's AddressSanitizer output from tests/basic with reproducer,
compiled with CFLAGS="-fsanitize=address -O0 -g":

$ tests/basic
=================================================================
==1665037==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000000388 at pc 0x7f36999058d0 bp 0x7ffdef3a5160 sp 0x7ffdef3a5150
READ of size 8 at 0x603000000388 thread T0
    #0 0x7f36999058cf in _gcry_mpi_invm ../../mpi/mpi-inv.c:530
    #1 0x7f369970a270 in gcry_mpi_invm ../../src/visibility.c:472
    #2 0x5608cc442631 in test_cryptofuzz ../../tests/basic.c:13901
    #3 0x5608cc442ffb in main ../../tests/basic.c:14019
    #4 0x7f36994d80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #5 0x5608cc411f4d in _start (/home/jussi/kernel/libgcrypt/build-amd64-ubsan/tests/basic+0x5bf4d)

0x603000000388 is located 0 bytes to the right of 24-byte region [0x603000000370,0x603000000388)
allocated by thread T0 here:
    #0 0x7f3699ad0bc8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x7f36997253ab in _gcry_private_malloc ../../src/stdmem.c:113
    #2 0x7f36997137af in do_malloc ../../src/global.c:920
    #3 0x7f369971395e in _gcry_malloc ../../src/global.c:942
    #4 0x7f3699714007 in _gcry_xmalloc ../../src/global.c:1116
    #5 0x7f36999142f0 in _gcry_mpi_alloc_limb_space ../../mpi/mpiutil.c:138
    #6 0x7f36999057f2 in _gcry_mpi_invm ../../mpi/mpi-inv.c:523
    #7 0x7f369970a270 in gcry_mpi_invm ../../src/visibility.c:472
    #8 0x5608cc442631 in test_cryptofuzz ../../tests/basic.c:13901
    #9 0x5608cc442ffb in main ../../tests/basic.c:14019
    #10 0x7f36994d80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

SUMMARY: AddressSanitizer: heap-buffer-overflow ../../mpi/mpi-inv.c:530 in _gcry_mpi_invm
Shadow bytes around the buggy address:
  0x0c067fff8020: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
  0x0c067fff8030: fa fa 00 00 00 fa fa fa fd fd fd fa fa fa fd fd
  0x0c067fff8040: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa
  0x0c067fff8050: 00 00 00 fa fa fa fd fd fd fa fa fa fd fd fd fa
  0x0c067fff8060: fa fa fd fd fd fa fa fa 00 00 00 fa fa fa 00 00
=>0x0c067fff8070: 00[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff80b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff80c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==1665037==ABORTING


I applied following change and that appears to avoid the heap-overflow, but
I'm not sure if this is correct fix:

diff --git a/mpi/mpi-inv.c b/mpi/mpi-inv.c
index 3ff5947a..a53a195a 100644
--- a/mpi/mpi-inv.c
+++ b/mpi/mpi-inv.c
@@ -526,7 +526,8 @@ _gcry_mpi_invm (gcry_mpi_t x, gcry_mpi_t a, gcry_mpi_t n)
       else
        _gcry_mpih_sub_n (diffp, x1p, x2p, x1size);
       _gcry_mpi_free_limb_space (x1p, x1size);
-      for (i = k % BITS_PER_MPI_LIMB; i < BITS_PER_MPI_LIMB; i++)
+      for (i = k % BITS_PER_MPI_LIMB;
+          i < BITS_PER_MPI_LIMB && k / BITS_PER_MPI_LIMB < x1size; i++)
        diffp[k/BITS_PER_MPI_LIMB] &= ~(((mpi_limb_t)1) << i);
 
       hsize = x1size * 2;



-Jussi

On 13.5.2020 9.44, Niibe Yutaka wrote:
> Guido Vranken via Gcrypt-devel wrote:
>> Here is a reproducer for the bugs. OOB reads and writes on i386:
> 
> Thanks.  It was me who embugged.  It was just fixed by the commit:
> 
> 	69b55f87053ce2494cd4b38dc600f867bc4355be
> 
> By the way, the problem in your original report was also fixed.
> Now, it should return correct value (if inverse exists or not).
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: poc_22305.c
Type: text/x-csrc
Size: 663 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20200529/0f9c2483/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cryptofuzz-reproducer-tests-basic.c.patch
Type: text/x-patch
Size: 1640 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20200529/0f9c2483/attachment.bin>