[Touch-packages] [Bug 2058775]

[Andreas Schwab]

dup

*** This bug has been marked as a duplicate of bug 28943 ***

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

Title:
  coreutils: printf formatting bug for nb_NO and nn_NO locales

Status in GLibC:
  Invalid
Status in coreutils package in Ubuntu:
  New

Bug description:
  I just discovered a printf bug for at least the nb_NO and nn_NO
  locales when printing numbers with thousands separator. To reproduce:

  #!/bin/bash
  for l in de_DE en_US nb_NO ; do
     echo "LC_NUMERIC=$l.UTF-8"
     for n in 1 100 1000 1 10 100 1000 ; do
    LC_NUMERIC=$l.UTF-8 /usr/bin/printf "<%'10d>\n" $n
     done
  done

  The expected output of "%'10d" is a right-formatted number string with
  10 characters.

  The output of the test script is fine for e.g. LC_NUMERIC=de_DE.UTF-8
  and LC_NUMERIC=en_US.UTF-8:

  LC_NUMERIC=de_DE.UTF-8
  < 1>
  <   100>
  < 1.000>
  <10.000>
  <   100.000>
  < 1.000.000>
  <10.000.000>
  LC_NUMERIC=en_US.UTF-8
  < 1>
  <   100>
  < 1,000>
  <10,000>
  <   100,000>
  < 1,000,000>
  <10,000,000>

  However, for LC_NUMERIC=nb_NO.UTF-8 and LC_NUMERIC=nn_NO.UTF-8, the
  formatting is wrong:

  LC_NUMERIC=nb_NO.UTF-8
  < 1>
  <   100>
  <   1 000>
  <  10 000>
  < 100 000>
  <1 000 000>
  <10 000 000>
  LC_NUMERIC=nn_NO.UTF-8
  < 1>
  <   100>
  <   1 000>
  <  10 000>
  < 100 000>
  <1 000 000>
  <10 000 000>

  I reproduced the issue with coreutils-8.32-4.1ubuntu1.1 (Ubuntu 22.04)
  as well as coreutils-9.3-5.fc39.x86_64 (Fedora 39).

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: coreutils 8.32-4.1ubuntu1.1
  ProcVersionSignature: Ubuntu 6.5.0-26.26~22.04.1-generic 6.5.13
  Uname: Linux 6.5.0-26-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: KDE
  Date: Fri Mar 22 21:33:13 2024
  InstallationDate: Installed on 2022-11-29 (479 days ago)
  InstallationMedia: Kubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 
(20220809.1)
  SourcePackage: coreutils
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/2058775/+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 305901]

[Andreas Schwab]

The point of _FORTIFY_SOURCE is to expose undefined behaviour.

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

Title:
  Intrepid gcc -O2 breaks string appending with sprintf(), due to
  fortify source patch

Status in GLibC:
  Confirmed
Status in 4g8 package in Ubuntu:
  Invalid
Status in abiword package in Ubuntu:
  Invalid
Status in asterisk package in Ubuntu:
  Invalid
Status in atomicparsley package in Ubuntu:
  Invalid
Status in audacious-plugins package in Ubuntu:
  Invalid
Status in barnowl package in Ubuntu:
  Invalid
Status in billard-gl package in Ubuntu:
  Invalid
Status in binutils package in Ubuntu:
  Invalid
Status in blender package in Ubuntu:
  Invalid
Status in ctn package in Ubuntu:
  Invalid
Status in gcc-4.3 package in Ubuntu:
  Invalid
Status in glibc package in Ubuntu:
  Fix Released
Status in hypermail package in Ubuntu:
  Invalid
Status in mpeg4ip package in Ubuntu:
  Invalid
Status in nagios-plugins package in Ubuntu:
  Invalid
Status in owl package in Ubuntu:
  Invalid
Status in xmcd package in Ubuntu:
  Invalid
Status in 4g8 source package in Intrepid:
  Invalid
Status in abiword source package in Intrepid:
  Invalid
Status in asterisk source package in Intrepid:
  Invalid
Status in atomicparsley source package in Intrepid:
  Invalid
Status in audacious-plugins source package in Intrepid:
  Invalid
Status in barnowl source package in Intrepid:
  Invalid
Status in billard-gl source package in Intrepid:
  Invalid
Status in binutils source package in Intrepid:
  Invalid
Status in blender source package in Intrepid:
  Invalid
Status in ctn source package in Intrepid:
  Invalid
Status in gcc-4.3 source package in Intrepid:
  Invalid
Status in glibc source package in Intrepid:
  Fix Released
Status in hypermail source package in Intrepid:
  Invalid
Status in mpeg4ip source package in Intrepid:
  Invalid
Status in nagios-plugins source package in Intrepid:
  Invalid
Status in owl source package in Intrepid:
  Invalid
Status in xmcd source package in Intrepid:
  Invalid
Status in 4g8 source package in Jaunty:
  Invalid
Status in abiword source package in Jaunty:
  Invalid
Status in asterisk source package in Jaunty:
  Invalid
Status in atomicparsley source package in Jaunty:
  Invalid
Status in audacious-plugins source package in Jaunty:
  Invalid
Status in barnowl source package in Jaunty:
  Invalid
Status in billard-gl source package in Jaunty:
  Invalid
Status in binutils source package in Jaunty:
  Invalid
Status in blender source package in Jaunty:
  Invalid
Status in ctn source package in Jaunty:
  Invalid
Status in gcc-4.3 source package in Jaunty:
  Invalid
Status in glibc source package in Jaunty:
  Fix Released
Status in hypermail source package in Jaunty:
  Invalid
Status in mpeg4ip source package in Jaunty:
  Invalid
Status in nagios-plugins source package in Jaunty:
  Invalid
Status in owl source package in Jaunty:
  Invalid
Status in xmcd source package in Jaunty:
  Invalid

Bug description:
  Binary package hint: gcc-4.3

  In Hardy and previous releases, one could use statements such as
sprintf(buf, "%s %s%d", buf, foo, bar);
  to append formatted text to a buffer buf.  Intrepid’s gcc-4.3, which has 
fortify source turned on by default when compiling with -O2, breaks this 
pattern.  This introduced mysterious bugs into an application I was compiling 
(the BarnOwl IM client).

  Test case: gcc -O2 sprintf-test.c -o sprintf-test
  :
#include 
char buf[80] = "not ";
int main()
{
sprintf(buf, "%sfail", buf);
puts(buf);
return 0;
}
  This outputs "not fail" in Hardy, and "fail" in Intrepid.

  The assembly output shows that the bug has been introduced by
  replacing the sprintf(buf, "%sfail", buf) call with __sprintf_chk(buf,
  1, 80, "%sfail", buf).  A workaround is to disable fortify source (gcc
  -U_FORTIFY_SOURCE).

  One might argue that this usage of sprintf() is questionable.  I had
  been under the impression that it is valid, and found many web pages
  that agree with me, though I was not able to find an authoritative
  statement either way citing the C specification.  I decided to
  investigate how common this pattern is in real source code.

  You can search a source file for instances of it with this regex:
pcregrep -M 'sprintf\s*\(\s*([^,]*)\s*,\s*"%s[^"]*"\s*,\s*\1\s*,'

  To determine how common the pattern is, I wrote a script to track down 
instances using Google Code Search, and found 2888 matches:

  (For the curious: the script uses a variant of the regex above.  I had to use 
a binary search to emulate backreferences, which aren’t supported by Code 
Search, so the script makes 46188 queries and takes a rather long time to run.  
The source is available at