[pkg-gnupg-maint] Bug#944914: Bug#944914: libgpgme11: Buffer overflow while using claws-mail

Daniel Kahn Gillmor dkg at fifthhorseman.net
Fri Feb 12 16:11:58 GMT 2021


Control: tags 944914 + moreinfo unreproducible

Hi Lars--

On Sun 2019-11-17 16:53:33 +0100, Lars Kruse wrote:
> I am using the claws-mail package for handling emails (Debian testing
> on i386).
>
> Due to repeated crashes, I started to collect stack traces.

Are you still having these problems?

Bernhard Ãœbelacker wrote:

>    Maybe it is of some help, following seem to be locations with the
>    missing symbols:
>        ...
>        #8  0xb6441a7a in __fdelt_chk (d=194142480) at fdelt_chk.c:25
>        #9  0xb27e5281 in  () at libgpgme.so.11, in _gpgme_io_select at ../../src/posix-io.c:788
>        #10 0xb27bf7fc in  () at libgpgme.so.11, in _gpgme_wait_on_condition at ../../src/wait-private.c:87
>        #11 0xb27bf9ec in  () at libgpgme.so.11, in _gpgme_wait_one at ../../src/wait-private.c:170
>        #12 0xb27c5201 in gpgme_op_verify () at libgpgme.so.11, ../../src/verify.c, line 1197.
>        ...


if i'm understanding correctly, this failure in fdelt_chk, which is due
to a violation of a precondition of one of the FD_* macros:

  https://stackoverflow.com/questions/41212302/c-debugging-terminated-with-sigabrt

the referenced code in _gpgme_io_select (taken from 1.13.1-1, with
debian patches applied) is almost 20 years old:

```
    781 d61bf6c13 gpgme/posix-io.c (Marcus Brinkmann    2007-07-17 12:36:04 +0000 781)   /* The variable N is used to optimize it a little bit.  */
    782 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 782)   for (n = count, i = 0; i < nfds && n; i++)
    783 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 783)     {
    784 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 784)       if (fds[i].fd == -1)
    785 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 785)  ;
    786 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 786)       else if (fds[i].for_read)
    787 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 787)  {
    788 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 788)    if (FD_ISSET (fds[i].fd, &readfds))
    789 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 789)      {
    790 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 790)        fds[i].signaled = 1;
    791 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 791)        n--;
    792 6bf05e9c0 gpgme/posix-io.c (Werner Koch         2000-11-22 17:10:48 +0000 792)             }
    793 6bf05e9c0 gpgme/posix-io.c (Werner Koch         2000-11-22 17:10:48 +0000 793)         }
    794 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 794)       else if (fds[i].for_write)
    795 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 795)  {
    796 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 796)    if (FD_ISSET (fds[i].fd, &writefds))
    797 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 797)      {
    798 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 798)        fds[i].signaled = 1;
    799 6cee0a4f3 gpgme/posix-io.c (Marcus Brinkmann    2002-03-18 00:04:06 +0000 799)        n--;
    800 6bf05e9c0 gpgme/posix-io.c (Werner Koch         2000-11-22 17:10:48 +0000 800)             }
    801 6bf05e9c0 gpgme/posix-io.c (Werner Koch         2000-11-22 17:10:48 +0000 801)         }
    802 6bf05e9c0 gpgme/posix-io.c (Werner Koch         2000-11-22 17:10:48 +0000 802)     }
    803 d61bf6c13 gpgme/posix-io.c (Marcus Brinkmann    2007-07-17 12:36:04 +0000 803)   return TRACE_SYSRES (count);
    804 6bf05e9c0 gpgme/posix-io.c (Werner Koch         2000-11-22 17:10:48 +0000 804) }
```

And yes, it does appear to be triggering on FD_ISSET -- so either
fds[i].fd is < 0, or it is > FD_SETSIZE:

   https://sourceware.org/git/?p=glibc.git;a=blob;f=debug/fdelt_chk.c;h=7fe243d2174211257976ca95091b507c2a9499bd;hb=HEAD

But code earlier in _gpgme_io_select appears to try to verify that we
don't overflow these bounds, as described in
https://dev.gnupg.org/rM8173c4f1f8a145c4b1d454f6f05e26950e23d675, and i
don't see how ctx->fdt.fds could land in that range anyway.

So i'm pretty stumped as to why or how this could be happening (and i
haven't been able to hit it myself).  If it's still going on, or if
you've found a way that i might be able to reproduce it, please respond
to this bug report.

Thanks,

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20210212/06a3bfee/attachment.sig>


More information about the pkg-gnupg-maint mailing list