touch-packages team mailing list archive

[Tom Yu <tlyu@xxxxxxx>]

This problem is broader than slave KDCs; it can potentially affect any
write operation on a KDC with sufficiently many (more than a few
hundred) principals, causing database corruption or denial of service.
Altering the test case to create one principal per invocation of
kadmin.local shows that the spin condition depends on database contents
rather than process memory history.

It also manifests during krb5_db_get_principal(), not just
krb5_db_put_principal(), as shown in the below stack trace.  Note the
krb5_db_get_principal() call in the stack trace is the one that is meant
to verify the master key.

Altered test case showing the spin condition on a fresh kadmin.local
invocation:

kdb5_util -W -r T create -s
awk 'BEGIN { for (i = 0; i < 1024; i++) { printf("%06d\n", i) } }' /dev/null | (set -e; while read p; do kadmin.local -r T -q "ank -randkey $p"; done)

I still recommend preferring the test case I gave in comment #1 because
it executes more quickly.

kadmin.local stack trace:

(gdb) bt
#0  0x00007f3fa70dbcbc in ?? ()
   from /usr/lib/x86_64-linux-gnu/krb5/plugins/kdb/db2.so
#1  0x00007f3fa70d90bc in ?? ()
   from /usr/lib/x86_64-linux-gnu/krb5/plugins/kdb/db2.so
#2  0x00007f3fa70d7bc9 in ?? ()
   from /usr/lib/x86_64-linux-gnu/krb5/plugins/kdb/db2.so
#3  0x00007f3fa70d0ab6 in ?? ()
   from /usr/lib/x86_64-linux-gnu/krb5/plugins/kdb/db2.so
#4  0x00007f3fa70d1bf4 in ?? ()
   from /usr/lib/x86_64-linux-gnu/krb5/plugins/kdb/db2.so
#5  0x00007f3fa79d0047 in krb5_db_get_principal ()
   from /usr/lib/x86_64-linux-gnu/libkdb5.so.7
#6  0x00007f3fa79d365b in ?? () from /usr/lib/x86_64-linux-gnu/libkdb5.so.7
#7  0x00007f3fa79d02c0 in krb5_db_fetch_mkey_list ()
   from /usr/lib/x86_64-linux-gnu/libkdb5.so.7
#8  0x00007f3fa9140f78 in kdb_init_master ()
   from /usr/lib/x86_64-linux-gnu/libkadm5srv_mit.so.9
#9  0x00007f3fa9141e90 in kadm5_init ()
   from /usr/lib/x86_64-linux-gnu/libkadm5srv_mit.so.9
#10 0x0000000000404659 in ?? ()
#11 0x0000000000402bbc in ?? ()
#12 0x00007f3fa8263ec5 in __libc_start_main (main=0x402b70, argc=5, 
    argv=0x7fff76716738, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fff76716728) at libc-start.c:287
#13 0x0000000000402c96 in ?? ()

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gcc-4.8 in Ubuntu.
https://bugs.launchpad.net/bugs/1347147

Title:
  krb5 database propagation enters infinite loop

Status in The GNU Compiler Collection:
  Unknown
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  New
Status in “krb5” package in Ubuntu:
  Triaged

Bug description:
  In some conditions, propagating a kerberos database to a slave KDC server can stall.
  This is due to a misoptimization by gcc 4.8 of the CIRCLEQ famliy of macros, apparently due to overzealous strict aliasing deductions.

  One case of this stall is reported at
  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html (and
  the rest of the thread), and there is an entry in the upstream
  bugtracker at http://krbdev.mit.edu/rt/Ticket/Display.html?id=7860 .

  gcc 4.9 (as used in Debian unstable at present) is not believed to
  induce this problem.  Upstream has patched their code to use the TAILQ
  family of macros instead, as a workaround, but that workaround has not
  yet appeared in an upstream release:
  https://github.com/krb5/krb5/commit/26d8744129

  Because of the different compiler versions used on Debian and Ubuntu,
  I am filing this as an Ubuntu-specific bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc/+bug/1347147/+subscriptions