[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Steve Langasek]

This is a bug specific to the C language, which is not applicable to the
in-progress gccgo-4.9 SRU.  Marking as resolved.

** Tags removed: verification-needed
** Tags added: verification-done

-- 
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 operations enter infinite loop

Status in gcc:
  Fix Released
Status in Kerberos:
  Unknown
Status in gcc-4.8 package in Ubuntu:
  Fix Released
Status in gcc-4.9 package in Ubuntu:
  Fix Released
Status in krb5 package in Ubuntu:
  Fix Released
Status in gcc-4.8 source package in Trusty:
  Fix Released
Status in krb5 source package in Trusty:
  Fix Released

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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:
  h

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Steve Langasek]

Hello Benjamin, or anyone else affected,

Accepted gccgo-4.9 into trusty-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/gccgo-4.9/4.9.3-0ubuntu4 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Tags removed: verification-done

** Tags added: verification-needed

-- 
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 operations enter infinite loop

Status in gcc:
  Fix Released
Status in Kerberos:
  Unknown
Status in gcc-4.8 package in Ubuntu:
  Fix Released
Status in gcc-4.9 package in Ubuntu:
  Fix Released
Status in krb5 package in Ubuntu:
  Fix Released
Status in gcc-4.8 source package in Trusty:
  Fix Released
Status in krb5 source package in Trusty:
  Fix Released

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the c

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Launchpad Bug Tracker]

This bug was fixed in the package gcc-4.8 - 4.8.4-2ubuntu1~14.04

---
gcc-4.8 (4.8.4-2ubuntu1~14.04) trusty-proposed; urgency=medium

  * SRU LP: #1311866.
  * Fix PR tree-optimization/63341 (wrong code, rs6000).
  * Allow to turn off -Wformat using Wno-format. LP: #1401836.
  * Fix PR target/60693 (x86, ice on valid code). LP: #1378737.
  * Fix PR tree-optimization/61964 (wrong code). LP: #1347147.
  * Fix GCC miscompilation with boost::asio::io_service::work. LP: #1338693.
  * Fix PR target/61208 (POWER, wrong code). LP: #1322287.
  * Fix ABI incompatibility between POWER and Z HTM builtins and intrinsics.
LP: #1320292.
  * Fix PR c++/61046 (ice on invalid code). LP: #1313102.
  * Fix wrong-code issue in the little endian vector API (ppc64el).
LP: #1311128.
  * Fix PR tree-optimization/59358 (wrong code). LP: #1395019.
  * Fix ice on ARM32. LP: #1268893.
  * Don't apply the backport for PR61841 for trusty, causing link failures.
  * Fix wrong code for vector doubleword extract (POWER). LP: #1437467.

gcc-4.8 (4.8.4-2ubuntu1) vivid; urgency=medium

  * Merge with Debian; remaining changes:
- Build from the upstream source.

gcc-4.8 (4.8.4-2) unstable; urgency=medium

  * Update to SVN 20150426 (r222448) from the gcc-4_8-branch.
- Fix PR libstdc++/60966, PR c/61553, PR middle-end/63704,
  PR target/61413 (ARM), PR target/64358 (RS6000), PR target/64479 (SH),
  PR target/64409 (x86), PR rtl-optimization/64037, PR c++/64487,
  PR c++/64251, PR c++/64297, PR fortran/63733, PR fortran/64244,
  PR c/64766, PR target/64882, PR rtl-optimization/61058,
  PR middle-end/43631, PR tree-optimization/64563, PR target/64513,
  PR middle-end/57748, PR middle-end/57748, PR target/64795,
  PR fortran/64528, PR fortran/56867, PR fortran/57023, PR c/57653,
  PR tree-optimization/63844 (OpenMP), PR middle-end/64199 (ice on valid),
  PR tree-optimization/64493 (ice on valid), PR tree-optimization/64495
  (wrong code), PR tree-optimization/56273 (diagnostics),
  PR tree-optimization/59124 (diagnostic), PR tree-optimization/64277
  (diagnostic), PR lto/65015, PR target/65163 (SH), PR target/64113 (ALPHA,
  link failure), PR rtl-optimization/64557, PR rtl-optimization/63475
  (ALPHA, wrong code), PR rtl-optimization/63483 (ALPHA, wrong code),
  PR target/64452 (AVR), PR target/64387 (x86, ice on valid),
  PR target/64979 (wrong code), PR target/64580 (rs6000),
  PR fortran/63744 (rejects valid), PR lto/65193 (ice on valid),
  PR tree-optimization/61634 (ice on valid), PR target/65196 (AVR),
  PR tree-optimization/63593 (ice on valid),
  PR tree-optimization/65063 (wrong code), PR target/65286 (rs6000),
  PR 65138/target (rs6000), PR target/53988 (SH), PR target/59593 (ARM),
  PR target/64453 (ARM), PR middle-end/65409 (ice on valid),
  PR tree-optimization/65388, PR fortran/65024 (ice),
  PR fortran/60898 (ice on valid), PR fortran/61138, PR libgfortran/60956,
  PR libstdc++/65279, PR libstdc++/65543, PR target/65849, PR target/65456,
  PR target/65787, PR c++/65727, PR c++/65721, PR fortran/56674,
  PR fortran/58813, PR fortran/59016, PR fortran/59024,
  PR libgfortran/59513.
- s390 hotpatch backport.
- ppc64: Backport little endian swap optimization.
  * Allow to build using gettext built with a newer GCC.
  * Backport PR c++/62255 (rejects-valid).
  * Update the Linaro support to the 4.8-2015.02 release.
  * Configure with --enable-targets=powerpcle-linux on ppc64el for
backports to jessie, trusty, utopic and vivid.
  * [AArch64] Fix output template for Scalar Neon->Neon register move.
LP: #1435342.
  * Limit the omp.h multilib fix to Linux. Addresses: #778440.
  * For ICEs, dump the preprocessed source file to stderr when in a
distro build environment.
  * Apply the ada-mips patch for mips and mipsel targets only.

gcc-4.8 (4.8.4-1ubuntu15) vivid; urgency=medium

  * Update to SVN 20150327 (r221736) from the gcc-4_8-branch.
- Fix PR libstdc++/65279, PR libstdc++/65543.
- ppc64: Backport little endian swap optimization.
  * Limit the omp.h multilib fix to Linux. Addresses: #778440.
  * For ICEs, dump the preprocessed source file to stderr when in a
distro build environment.
  * Apply the ada-mips patch for mips and mipsel targets only.

gcc-4.8 (4.8.4-1ubuntu14) vivid; urgency=medium

  * [AArch64] Fix output template for Scalar Neon->Neon register move.
LP: #1435342.

gcc-4.8 (4.8.4-1ubuntu11) vivid; urgency=medium

  * Update to SVN 20150323 (r221594) from the gcc-4_8-branch.
- Fix PR fortran/61138, PR libgfortran/60956.
  * Configure with --enable-targets=powerpcle-linux on ppc64el for vivid.

gcc-4.8 (4.8.4-1ubuntu10) vivid; urgency=medium

  * Update to SVN 20150319 (r221517) from the gcc-4_8-branch.
- Fix PR middle-end/65409 (ice on valid), PR tree-optimization/65388,
  PR fortran/65024 (ice), PR fortran/60898 (ice on valid).
  * Config

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Matthias Klose]

checked with 4.8.4-2ubuntu1~14.04


** Tags removed: verification-needed
** Tags added: verification-done

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in gcc-4.8 package in Ubuntu:
  Fix Released
Status in gcc-4.9 package in Ubuntu:
  Fix Released
Status in krb5 package in Ubuntu:
  Fix Released
Status in gcc-4.8 source package in Trusty:
  Fix Committed
Status in krb5 source package in Trusty:
  Fix Released

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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/26d874

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Steve Langasek]

Hello Benjamin, or anyone else affected,

Accepted gcc-4.8 into trusty-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/gcc-4.8/4.8.4-2ubuntu1~14.04 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: gcc-4.8 (Ubuntu Trusty)
   Status: Confirmed => Fix Committed

** Tags removed: verification-done

** Tags added: verification-needed

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in gcc-4.8 package in Ubuntu:
  Fix Released
Status in gcc-4.9 package in Ubuntu:
  Fix Released
Status in krb5 package in Ubuntu:
  Fix Released
Status in gcc-4.8 source package in Trusty:
  Fix Committed
Status in krb5 source package in Trusty:
  Fix Released

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ ma

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Launchpad Bug Tracker]

This bug was fixed in the package krb5 - 1.12+dfsg-2ubuntu5

---
krb5 (1.12+dfsg-2ubuntu5) trusty; urgency=low

  * Use ADD_METHOD_NOLOOP rather than ADD_METHOD for new GSS-API entry
points, avoids infinite recursive loop when a mechanism doesn't
provide an entry point and does include  calls back into the mechglue
(LP: #1326500)
  * Make libkadm5srv-mit8 be arch: any multi-arch: same to work around
upgrade bug (LP: #1334052)
  * Use tailq macros to work around GCC 4.8 optimizer bug and prevent
infinite loop for database propagation (LP: #1347147)
 -- Sam HartmanWed, 30 Jul 2014 21:06:49 -0400

** Changed in: krb5 (Ubuntu Trusty)
   Status: Fix Committed => Fix Released

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in gcc-4.8 package in Ubuntu:
  Fix Released
Status in gcc-4.9 package in Ubuntu:
  Fix Released
Status in krb5 package in Ubuntu:
  Fix Released
Status in gcc-4.8 source package in Trusty:
  Confirmed
Status in krb5 source package in Trusty:
  Fix Released

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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 macro

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Mathew Hodson]

** Branch linked: lp:ubuntu/trusty-proposed/krb5

** Branch unlinked: lp:debian/gnat-4.9

** Branch linked: lp:ubuntu/utopic-proposed/gcc-4.8

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in gcc-4.8 package in Ubuntu:
  Fix Released
Status in gcc-4.9 package in Ubuntu:
  Fix Released
Status in krb5 package in Ubuntu:
  Fix Released
Status in gcc-4.8 source package in Trusty:
  Confirmed
Status in krb5 source package in Trusty:
  Fix Committed

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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://g

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Tom Yu]

Confirmed that 1.12+dfsg-2ubuntu5 from trusty-proposed fixes the bug on
amd64.

** Tags removed: verification-needed
** Tags added: verification-done

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Released
Status in “gcc-4.8” source package in Trusty:
  Confirmed
Status in “krb5” source package in Trusty:
  Fix Committed

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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 re

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Brian Murray]

Hello Benjamin, or anyone else affected,

Accepted krb5 into trusty-proposed. The package will build now and be
available at http://launchpad.net/ubuntu/+source/krb5/1.12+dfsg-2ubuntu5
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: krb5 (Ubuntu Trusty)
   Status: In Progress => Fix Committed

** Tags added: verification-needed

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Released
Status in “gcc-4.8” source package in Trusty:
  Confirmed
Status in “krb5” source package in Trusty:
  Fix Committed

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be saf

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Anders Kaseorg]

It’s currently sitting in Unapproved:

https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=krb5

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Released
Status in “gcc-4.8” source package in Trusty:
  Confirmed
Status in “krb5” source package in Trusty:
  In Progress

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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/co

Re: [Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Sam Hartman]

> "Iain" == Iain Lane  writes:

Iain> Thanks Sam, I've uploaded krb5.  ** Changed in: krb5 (Ubuntu
Iain> Trusty) Status: Triaged => In Progress

Hi.
I haven't seen this hit proposed yet.
Is that expected?  What is the next step?

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Released
Status in “gcc-4.8” source package in Trusty:
  Confirmed
Status in “krb5” source package in Trusty:
  In Progress

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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 macr

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Iain Lane]

Thanks Sam, I've uploaded krb5.

** Changed in: krb5 (Ubuntu Trusty)
   Status: Triaged => In Progress

** Changed in: krb5 (Ubuntu Trusty)
 Assignee: (unassigned) => Sam Hartman (hartmans)

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Released
Status in “gcc-4.8” source package in Trusty:
  Confirmed
Status in “krb5” source package in Trusty:
  In Progress

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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 worka

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Launchpad Bug Tracker]

** Branch linked: lp:debian/gnat-4.9

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Released
Status in “gcc-4.8” source package in Trusty:
  Confirmed
Status in “krb5” source package in Trusty:
  Triaged

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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 an

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Anders Kaseorg]

A second patch was committed a few days ago for another case of the GCC
bug (https://gcc.gnu.org/PR62004).

trunk: https://gcc.gnu.org/r213970
4.9: https://gcc.gnu.org/r214044
4.8: https://gcc.gnu.org/r214067

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Released
Status in “gcc-4.8” source package in Trusty:
  Confirmed
Status in “krb5” source package in Trusty:
  Triaged

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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 tha

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Duncan White]

Hi, I'm from the original organisation (doc.ic.ac.uk) with the kdc5_util load 
problem on Trusty,
I appreciate all your work on fixing this bug.  If it's useful info, I can 
confirm that taking the
krb5 (1.12.1+dfsg-7) source package [revised version of 1.12.1+dfsg-6 mentioned 
above] from
Utopic and locally backporting it onto Trusty, and installing the relevant krb5 
packages onto
our experimental slave KDC does fix the original kprop/kdc5_util load problem.  
So I'm temporarily
using that until proper Trusty packages come out.

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Released
Status in “gcc-4.8” source package in Trusty:
  Confirmed
Status in “krb5” source package in Trusty:
  Triaged

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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
  th

Re: [Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Sam Hartman]

> "Robie" == Robie Basak <1347...@bugs.launchpad.net> writes:

Robie> Thanks Sam. I'm sorry I can't sponsor krb5, only triage the
Robie> bug and guide it through to sponsorship. It looks like you
Robie> know what you're doing here, so I guess we'll just need to
Robie> wait for a sponsor to look at it. I can see that it's in the
Robie> queue and working its way up.

Actually, your reassurance that we've done the right things process wise
is really helpful.
I've been involved in Debian for over 10 years but haven't done a huge
bunch of stuff with Ubuntu so I'm mostly just reading the wikis and
trying to figure it out:-)

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Released
Status in “gcc-4.8” source package in Trusty:
  Confirmed
Status in “krb5” source package in Trusty:
  Triaged

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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.

 

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Robie Basak]

Thanks Sam. I'm sorry I can't sponsor krb5, only triage the bug and
guide it through to sponsorship. It looks like you know what you're
doing here, so I guess we'll just need to wait for a sponsor to look at
it. I can see that it's in the queue and working its way up.

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Released
Status in “gcc-4.8” source package in Trusty:
  Confirmed
Status in “krb5” source package in Trusty:
  Triaged

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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 th

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Sam Hartman]

Here's an ubdated debdiff that includes the security update applied to
trusty.  I'm still waiting for a sponsor for this.

** Patch removed: "debdiff between current trusty and linked branch"
   
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1347147/+attachment/4166949/+files/krb5-trusty-stable.debdiff

** Patch added: "Debdiff of lp:~hartmans/ubuntu/trusty/krb5/gss-infinite-loop"
   
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1347147/+attachment/4175346/+files/krb5_1.12%2Bdfsg-2ubuntu5.debdiff

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Released
Status in “gcc-4.8” source package in Trusty:
  Confirmed
Status in “krb5” source package in Trusty:
  Triaged

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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)

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Launchpad Bug Tracker]

** Branch linked: lp:debian/gcc-4.9

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Released
Status in “gcc-4.8” source package in Trusty:
  Confirmed
Status in “krb5” source package in Trusty:
  Triaged

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: gcc-4.8 (Ubuntu Trusty)
   Status: New => Confirmed

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Released
Status in “gcc-4.8” source package in Trusty:
  Confirmed
Status in “krb5” source package in Trusty:
  Triaged

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Launchpad Bug Tracker]

This bug was fixed in the package krb5 - 1.12.1+dfsg-6

---
krb5 (1.12.1+dfsg-6) unstable; urgency=medium


  [ Benjamin Kaduk ]
  * Apply upstream's patch to switch to TAILQ macros instead of CIRCLEQ macros,
to work around an issue with certain gcc versions.  This is expected to
resolve Ubuntu bug (LP: #1347147).

  [ Sam Hartman ]
  * Include a quick and dirty patch so we build cleanly with -O3 fixing
incorrect may be uninitialized warnings.

 -- Benjamin Kaduk   Tue, 29 Jul 2014 17:05:37 -0400

** Changed in: krb5 (Ubuntu)
   Status: Fix Committed => Fix Released

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Anders Kaseorg]

I verified that this is fixed in utopic-proposed by krb5 1.12.1+dfsg-6.

krb5 (1.12.1+dfsg-6) unstable; urgency=medium

  [ Benjamin Kaduk ]
  * Apply upstream's patch to switch to TAILQ macros instead of CIRCLEQ macros,
to work around an issue with certain gcc versions.  This is expected to
resolve Ubuntu bug (LP: #1347147).

  [ Sam Hartman ]
  * Include a quick and dirty patch so we build cleanly with -O3 fixing
incorrect may be uninitialized warnings.

 -- Benjamin Kaduk   Tue, 29 Jul 2014 17:05:37 -0400

krb5 (1.12.1+dfsg-5) unstable; urgency=high

  * Apply upstream patches for CVE-2014-4343, CVE-2014-4344, Closes: #755520,
Closes: #755521

 -- Benjamin Kaduk   Mon, 21 Jul 2014 17:27:10 -0400

krb5 (1.12.1+dfsg-4) unstable; urgency=high

  * Apply upstream patch for CVE-2014-4341, CVE-2014-4342, Closes: #753624,
Closes: #753625

 -- Benjamin Kaduk   Fri, 11 Jul 2014 13:43:19 -0400


** CVE added: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2014-4341

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2014-4342

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2014-4343

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2014-4344

** Changed in: krb5 (Ubuntu)
   Status: Triaged => Fix Committed

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Fix Released
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Fix Released
Status in “gcc-4.9” package in Ubuntu:
  Fix Released
Status in “krb5” package in Ubuntu:
  Fix Committed
Status in “gcc-4.8” source package in Trusty:
  New
Status in “krb5” source package in Trusty:
  Triaged

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when 

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Bug Watch Updater]

Launchpad has imported 19 comments from the remote bug at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.


On 2014-07-30T13:21:26+00:00 Anders Kaseorg wrote:

Kerberos is miscompiled by gcc-4.8.  The impact is detailed at
https://bugs.launchpad.net/bugs/1347147, but here is a reduced test
case.  The expected return is 0, but when compiled with gcc-4.8 -O2, it
returns 1.

$ cat bug.c

struct node { struct node *next, *prev; } node;
struct head { struct node *first; } heads[5];
int k = 2;
struct head *head = &heads[2];

int main()
{
  node.prev = (void *)head;
  head->first = &node;

  struct node *n = head->first;
  struct head *h = &heads[k];

  if (n->prev == (void *)h)
h->first = n->next;
  else
n->prev->next = n->next;

  n->next = h->first;
  return n->next == &node;
}

$ gcc-4.7 -Wall -O2 bug.c -o bug; ./bug; echo $?
0
$ gcc-4.8 -Wall -O2 bug.c -o bug; ./bug; echo $?
1
$ gcc-4.9 -Wall -O2 bug.c -o bug; ./bug; echo $?
0
$ dpkg -l gcc-4.7 gcc-4.8 gcc-4.9
[…]
ii  gcc-4.7  4.7.4-2ubuntu1  amd64  GNU C compiler
ii  gcc-4.8  4.8.3-6ubuntu1  amd64  GNU C compiler
ii  gcc-4.9  4.9.1-3ubuntu2  amd64  GNU C compiler

I bisected the point where the problem disappeared between 4.8 and 4.9
at r202525.  However, I don’t understand why.  I’m scared by the fact
that r202525 was intended to fix a “missed-optimization” bug (bug
58404).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1347147/comments/7


On 2014-07-30T13:39:40+00:00 Rguenth wrote:

The testcase is violating strict-aliasing rules as you access a struct head
as struct node here:

  if (n->prev == (void *)h)
h->first = n->next;
  else
n->prev->next = n->next;

as n->prev points to &heads[0] while h is &heads[2] (an out-of-bound pointer).
So n->prev is a struct head and you access a next field of a struct node of it.

Changing k to 0 makes the testcase pass (now you don't run into the bogus
path).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1347147/comments/8


On 2014-07-30T14:31:43+00:00 Greg Hudson wrote:

How do you conclude that n->prev points to &heads[0]?  node.prev
receives the value (void *)head, where head is initialized to &heads[2].
I cannot see any uses of &heads[0] in the test program.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1347147/comments/9


On 2014-07-30T20:21:04+00:00 Anders Kaseorg wrote:

(In reply to Richard Biener from comment #1)
> The testcase is violating strict-aliasing rules as you access a struct head
> as struct node here:

Agree with ghudson here: n->prev points to &heads[2], not &heads[0].

Although assigning a casted struct head * to a struct node * is arguably
sloppy, the standard does not prohibit it, as long as it is never
dereferenced in that form.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1347147/comments/10


On 2014-07-31T04:19:53+00:00 Anders Kaseorg wrote:

Another bisect between 4.7 and 4.8 shows that the bug appeared with
r189321 (bug 52009).

My test case has triggers the bug in more versions than Kerberos does:
as far as I can tell, Kerberos was unaffected until r192604.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1347147/comments/18


On 2014-07-31T09:29:28+00:00 Mikpelinux wrote:

I've been staring as this test case, and I cannot find any dereference
of a wrong-typed pointer value.  The only oddity I can find is that at

  if (n->prev == (void *)h)

n == &node, n->prev == (struct node *)&heads[2] (so wrong-typed), h ==
&heads[2], so there is a '==' being applied to a wrong-typed pointer.
Is that undefined behaviour?  I'll note that changing the test to

  if ((void *)n->prev == (void *)h)

still reproduces the wrong-code while looking technically Ok.

Also, there is no out-of-bounds error.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1347147/comments/19


On 2014-07-31T09:48:33+00:00 Andreas Schwab wrote:

Equality test against pointer to void is explicitly allowed by the
standard and implicitly converts the other pointer to void*.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1347147/comments/20


On 2014-07-31T10:05:28+00:00 Rguenth wrote:

(In reply to Anders Kaseorg from 

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Sam Hartman]

I've request a krb5 sync from debian unstable in
https://bugs.launchpad.net/bugs/1352438 that should fix this issue and
include some needed security fixes in utopic.

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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:

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Robie Basak]

** Changed in: krb5 (Ubuntu)
   Importance: Undecided => High

** Changed in: krb5 (Ubuntu Trusty)
   Importance: Undecided => High

** Changed in: krb5 (Ubuntu Trusty)
   Status: New => Triaged

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Launchpad Bug Tracker]

This bug was fixed in the package gcc-4.9 - 4.9.1-4ubuntu2

---
gcc-4.9 (4.9.1-4ubuntu2) utopic; urgency=medium

  * Update to SVN 20140802 (r213510) from the gcc-4_9-branch.
- Fix PR tree-optimization/61964. LP: #1347147.
  * Fix libphobos cross build.
 -- Matthias KloseSat, 02 Aug 2014 02:44:59 +0200

** Changed in: gcc-4.9 (Ubuntu)
   Status: New => Fix Released

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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 un

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Launchpad Bug Tracker]

This bug was fixed in the package gcc-4.8 - 4.8.3-7ubuntu1

---
gcc-4.8 (4.8.3-7ubuntu1) utopic; urgency=medium

  * Merge with Debian; remaining changes:
- Build from the upstream source.

gcc-4.8 (4.8.3-7) unstable; urgency=medium

  * Update to SVN 20140801 (r213447) from the gcc-4_8-branch.
- CVE-2014-5044, fix integer overflows in array allocation in libgfortran.
  Closes: #756325.
- Fix PR tree-optimization/61964. LP: #1347147.
  * Fix java.security symlink. Addresses: #756484.
 -- Matthias KloseFri, 01 Aug 2014 12:25:27 +0200

** Changed in: gcc-4.8 (Ubuntu)
   Status: Fix Committed => Fix Released

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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 rep

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/utopic-proposed/gcc-4.9

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Launchpad Bug Tracker]

** Branch linked: lp:debian/gcc-4.8

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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 

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Anders Kaseorg]

gcc-4.8 (4.8.3-7ubuntu1) utopic; urgency=medium

  * Merge with Debian; remaining changes:
- Build from the upstream source.

 -- Matthias Klose   Fri, 01 Aug 2014 12:25:27 +0200

gcc-4.8 (4.8.3-7) unstable; urgency=medium

  * Update to SVN 20140801 (r213447) from the gcc-4_8-branch.
- CVE-2014-5044, fix integer overflows in array allocation in libgfortran.
  Closes: #756325.
- Fix PR tree-optimization/61964. LP: #1347147.
  * Fix java.security symlink. Addresses: #756484.

 -- Matthias Klose   Fri, 01 Aug 2014 12:07:59 +0200

I verified that compiling with gcc-4.8 4.8.3-7ubuntu1 in utopic-proposed
fixes the problem.

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2014-5044

** Changed in: gcc-4.8 (Ubuntu)
   Status: Confirmed => Fix Committed

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  In some conditions, propagating a kerberos database to a slave KDC server can 
stall.
  This is due to a misopt

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Anders Kaseorg]

Upstream says this bug still exists in GCC 4.9, even though Kerberos
happens to be unaffected there. They have committed a patch to GCC trunk
, GCC 4.9  and
for GCC 4.8 .

I verified that GCC 4.8 with r213405 fixes the kadmin.local test.

** No longer affects: gcc-4.9 (Ubuntu Trusty)

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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 believ

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Anders Kaseorg]

** Also affects: gcc-4.9 (Ubuntu)
   Importance: Undecided
   Status: New

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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

 

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Martin Pitt]

** Also affects: krb5 (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: gcc-4.8 (Ubuntu Trusty)
   Importance: Undecided
   Status: New

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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

  Becaus

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Thomas Ward]

Nomination added for krb5 for Trusty per an email thread to bugcontrol.
It added for gcc as well but the email chain points to a SRU fix for
krb5 and not the compiler at this time.

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Sam Hartman]

debdiff included

** Patch added: "debdiff between current trusty and linked branch"
   
https://bugs.launchpad.net/gcc/+bug/1347147/+attachment/4166949/+files/krb5-trusty-stable.debdiff

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  A branch is linked including the upstream work around for this bug,
  along with two other patches to bugs already nominated for trusty
  applied to the krb5 in trusty.

  For utopic, the simplest fix is to rebuild krb5 with the compiler
  currently in utopic.  An alternative is to request that the Debian
  maintainers (both monitoring this bug for such a request) upload the
  upstream work around to Debian and sync that.  You could do an ubuntu-
  specific upload but it seems undesirable to introduce a change between
  Ubuntu and Debian when all the right parties are happy to avoid it.

  The upstream patch works around a compiler optimizer bug in the
  gcc-4.8 series, which incorrectly deduces that a strict aliasing
  violation has occurred and miscompiles part of the bundled libdb2
  library that the KDC database back end depends upon.  The
  miscompilation causes a data structure to contain an inappropriate
  cycle, which leads to an infinite loop when the structure is
  traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an affected gcc would cause the krb5 test suite to stall when it
  reached the libdb2 test suite.  (The test suite stall is how we became
  aware of the gcc optimizer bug.)

  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.

  Original report from Ben Kaduk:

  ==

  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

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Sam Hartman]

** Description changed:

- In some conditions, propagating a kerberos database to a slave KDC server can 
stall.
+ In some conditions, propagating a kerberos database to a slave KDC server or 
performing other database operations can stall.  As we've investigated the 
issue, it looks like a database with more than a few hundred principals is very 
likely to run into this issue.
  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
  
+ A branch is linked including  this upstream work around and two other
+ patches to bugs already nominated for trusty applied to the krb5 in
+ trusty.  We believe the impact is significant because this is likely to
+ be a problem for sites with a large database running trusty.  The
+ regression potential is very small.  The upstream work around changes
+ from one family of queue macros that are stable and well-tested to
+ another.
+ 
+ For utopic, the simplest fix is to rebuild krb5 with the compiler
+ currently in utopic.  An alternative is to request that the Debian
+ maintainers (both monitoring this bug for such a request) upload the
+ upstream work around to Debian and sync that.  You could do an ubuntu-
+ specific upload but it seems undesirable to introduce a change between
+ Ubuntu and Debian when all the right parties are happy to avoid it.
+ 
  Because of the different compiler versions used on Debian and Ubuntu, I
  am filing this as an Ubuntu-specific bug.

-- 
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 operations enter infinite loop

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

Bug description:
  [Impact]

  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are
  not so fortunate, they will encounter this bug in a production KDC
  when the number of principals crosses the threshold where this bug
  manifests, resulting in a service outage and possible database
  corruption.  Probably the only way to restore service in that
  situation is to install a patched KDC or to downgrade to an unaffected
  version.

  Both Trusty and Utopic amd64 have been verified to have this issue.

  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:

  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html

  Additional failure modes are likely

  The proposed fix at 
https://launchpad.net/~hartmans/+archive/ubuntu/ubuntu-fixes
  works around a compiler optimizer bug in the gcc-4.8 series, which 
incorrectly deduces that a strict aliasing violation has occurred and 
miscompiles part of the bundled libdb2 library that the KDC database back end 
depends upon.  The miscompilation causes a data structure to contain an 
inappropriate cycle, which leads to an infinite loop when the structure is 
traversed.

  [Test Case]

  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T

  (Enter any password for the master key when requested.)

  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762"
  on two examples.)

  To clean up,

  rm /etc/krb5kdc/principal*

  or

  krb5kdc -r T destroy

  but the latter can possibly enter the same infinite loop.

  [Regression Potential]

  Negligible.

  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this
  current issue.  I think this is rather unlikely.

  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with
  an aff

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Tom Yu]

Edited description to include text from Sam that was omitted when we
crossed edits.

** Description changed:

  [Impact]
  
  On krb5 KDC databases with more than a few hundred principals,
  operations can enter an infinite loop in the database library.  This
  affects both read and write operations.  If operators are fortunate,
  they will encounter this bug while testing a migration.  If they are not
  so fortunate, they will encounter this bug in a production KDC when the
  number of principals crosses the threshold where this bug manifests,
  resulting in a service outage and possible database corruption.
  Probably the only way to restore service in that situation is to install
  a patched KDC or to downgrade to an unaffected version.
  
  Both Trusty and Utopic amd64 have been verified to have this issue.
  
  One concrete reported example is an invocation of kdb5_util load (as
  part of a slave KDC propagation) spinning:
  
  http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html
  
  Additional failure modes are likely
  
- The proposed fix at 
https://launchpad.net/~hartmans/+archive/ubuntu/ubuntu-fixes
- works around a compiler optimizer bug in the gcc-4.8 series, which 
incorrectly deduces that a strict aliasing violation has occurred and 
miscompiles part of the bundled libdb2 library that the KDC database back end 
depends upon.  The miscompilation causes a data structure to contain an 
inappropriate cycle, which leads to an infinite loop when the structure is 
traversed.
+ A branch is linked including the upstream work around for this bug,
+ along with two other patches to bugs already nominated for trusty
+ applied to the krb5 in trusty.
+ 
+ For utopic, the simplest fix is to rebuild krb5 with the compiler
+ currently in utopic.  An alternative is to request that the Debian
+ maintainers (both monitoring this bug for such a request) upload the
+ upstream work around to Debian and sync that.  You could do an ubuntu-
+ specific upload but it seems undesirable to introduce a change between
+ Ubuntu and Debian when all the right parties are happy to avoid it.
+ 
+ The upstream patch works around a compiler optimizer bug in the gcc-4.8
+ series, which incorrectly deduces that a strict aliasing violation has
+ occurred and miscompiles part of the bundled libdb2 library that the KDC
+ database back end depends upon.  The miscompilation causes a data
+ structure to contain an inappropriate cycle, which leads to an infinite
+ loop when the structure is traversed.
  
  [Test Case]
  
  apt-get install krb5-kdc krb5-admin-server
  kdb5_util -W -r T create -s
  awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T
  
  (Enter any password for the master key when requested.)
  
  On platforms with this issue, kadmin.local spins consuming 100% CPU
  after a few hundred principals have been created.  (This is "a000762" on
  two examples.)
  
  To clean up,
  
  rm /etc/krb5kdc/principal*
  
  or
  
  krb5kdc -r T destroy
  
  but the latter can possibly enter the same infinite loop.
  
  [Regression Potential]
  
  Negligible.
  
  It is theoretically possible that our upstream workaround, which
  involves using TAILQ macros instead of CIRCLEQ macros in the bundled
  libdb2 that backs the KDC database, will have some as-yet undiscovered
  bugs or compiler interactions with consequences worse than this current
  issue.  I think this is rather unlikely.
  
  The patched libdb2 passes both the extensive libdb2 test suite and the
  rest of the krb5 test suite.  Prior to patching, compiling krb5 with an
  affected gcc would cause the krb5 test suite to stall when it reached
  the libdb2 test suite.  (The test suite stall is how we became aware of
  the gcc optimizer bug.)
  
  The BSD TAILQ macros are generally considered to be safer than the
  CIRCLEQ macros, and the various open-source BSD derivatives have made
  the corresponding change to their libdb sources years ago, with no
  reported ill effects that I can see.
  
- 
  Original report from Ben Kaduk:
  
  ==
  
  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 Ubu

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Tom Yu]

** Description changed:

- In some conditions, propagating a kerberos database to a slave KDC server or 
performing other database operations can stall.  As we've investigated the 
issue, it looks like a database with more than a few hundred principals is very 
likely to run into this issue.
+ [Impact]
+ 
+ On krb5 KDC databases with more than a few hundred principals,
+ operations can enter an infinite loop in the database library.  This
+ affects both read and write operations.  If operators are fortunate,
+ they will encounter this bug while testing a migration.  If they are not
+ so fortunate, they will encounter this bug in a production KDC when the
+ number of principals crosses the threshold where this bug manifests,
+ resulting in a service outage and possible database corruption.
+ Probably the only way to restore service in that situation is to install
+ a patched KDC or to downgrade to an unaffected version.
+ 
+ Both Trusty and Utopic amd64 have been verified to have this issue.
+ 
+ One concrete reported example is an invocation of kdb5_util load (as
+ part of a slave KDC propagation) spinning:
+ 
+ http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html
+ 
+ Additional failure modes are likely
+ 
+ The proposed fix at 
https://launchpad.net/~hartmans/+archive/ubuntu/ubuntu-fixes
+ works around a compiler optimizer bug in the gcc-4.8 series, which 
incorrectly deduces that a strict aliasing violation has occurred and 
miscompiles part of the bundled libdb2 library that the KDC database back end 
depends upon.  The miscompilation causes a data structure to contain an 
inappropriate cycle, which leads to an infinite loop when the structure is 
traversed.
+ 
+ [Test Case]
+ 
+ apt-get install krb5-kdc krb5-admin-server
+ kdb5_util -W -r T create -s
+ awk 'BEGIN{ for (i = 0; i < 1024; i++) { printf("ank -randkey a%06d\n", i) } 
}' /dev/null | kadmin.local -r T
+ 
+ (Enter any password for the master key when requested.)
+ 
+ On platforms with this issue, kadmin.local spins consuming 100% CPU
+ after a few hundred principals have been created.  (This is "a000762" on
+ two examples.)
+ 
+ To clean up,
+ 
+ rm /etc/krb5kdc/principal*
+ 
+ or
+ 
+ krb5kdc -r T destroy
+ 
+ but the latter can possibly enter the same infinite loop.
+ 
+ [Regression Potential]
+ 
+ Negligible.
+ 
+ It is theoretically possible that our upstream workaround, which
+ involves using TAILQ macros instead of CIRCLEQ macros in the bundled
+ libdb2 that backs the KDC database, will have some as-yet undiscovered
+ bugs or compiler interactions with consequences worse than this current
+ issue.  I think this is rather unlikely.
+ 
+ The patched libdb2 passes both the extensive libdb2 test suite and the
+ rest of the krb5 test suite.  Prior to patching, compiling krb5 with an
+ affected gcc would cause the krb5 test suite to stall when it reached
+ the libdb2 test suite.  (The test suite stall is how we became aware of
+ the gcc optimizer bug.)
+ 
+ The BSD TAILQ macros are generally considered to be safer than the
+ CIRCLEQ macros, and the various open-source BSD derivatives have made
+ the corresponding change to their libdb sources years ago, with no
+ reported ill effects that I can see.
+ 
+ 
+ Original report from Ben Kaduk:
+ 
+ ==
+ 
+ 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
  
- A branch is linked including  this upstream work around and two other
- patches to bugs already nominated for trusty applied to the krb5 in
- trusty.  We believe the impact is significant because this is likely to
- be a problem for sites with a large database running trusty.  The
- regression potential is very small.  The upstream work around changes
- from one family of queue macros that are stable and well-tested to
- another.
- 
- For utopic, the simplest fix is to rebuild krb5 with the compiler
- currently in utopic.  An alternative is to request that the Debian
- maintainers (both monitoring this bug for such a request) upload the
- upstream work around to Debian and sync that.  You could do an ubuntu-
- specific upload but it seems undesirable to introduce a change between
- Ubuntu and Debian when all the right parties are happy to avoid it.
- 
  Because of the different compiler versions used on Deb

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: gcc-4.8 (Ubuntu)
   Status: New => Confirmed

-- 
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 operations enter infinite loop

Status in The GNU Compiler Collection:
  Unknown
Status in Network Authentication System:
  Unknown
Status in “gcc-4.8” package in Ubuntu:
  Confirmed
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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1347147] Re: krb5 database operations enter infinite loop

[Tom Yu]

** Summary changed:

- krb5 database propagation enters infinite loop
+ krb5 database operations enter infinite loop

-- 
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 operations enter 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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp