[Bug 1954598] [NEW] gcc ignores large _Alignas specifiers on static .bss data

Sun Dec 12 17:16:28 UTC 2021

Public bug reported:

Instructions to reproduce: compile the following C program:
```
#include <stdio.h>

static _Alignas(4 << 20) int x;

int main(void) {
    printf("%#llx\n", (long long) &x);
    return 0;
}
```

using `gcc` with no arguments other than the program's filename (which
must end `.c` so that gcc interprets it as a C program), and run the
resulting a.out.

Expected behaviour: the program prints a number that's divisible by 2²²
(in hexadecimal, the resulting number will end with five zeroes, and the
preceding digit will be divisible by 4).

Actual behaviour: the program prints an arbitrary number that's
divisible by 2¹², but which is normally not divisible by 2²². (The exact
number varies between runs of the program; some example observed values
include 0x55c2be889000 and 0x55d2cd348000.)

This bug seems to be somehow specific to the way Ubuntu has configured
`gcc` – it doesn't show up on a Red Hat-based Linux system, or when
compiling using `clang`. As far as I can tell, the bug isn't in the
compiler portion of `gcc`, but rather in the driver process; something
in the arguments that it's passing to the linker is causing this
behaviour.

I suspect that the bug is related to position independent code. (In
particular, compiling with `gcc -fno-pie` will cause an error along the
line of `/usr/bin/ld: /tmp/cc6nztmN.o: relocation R_X86_64_32 against
`.bss' can not be used when making a PIE object; recompile with -fPIE`,
rather than linking successfully, which means that the linker has been
told by the compiler to make a position-independent executable even when
the user explicitly tells it not to.)

It is possible that this misbehaviour has been introduced intentionally
for security reasons (because requiring a large alignment for the
program image reduces the amount of security that address space layout
randomization can provide). However, in this case, I think the correct
behaviour should be to reject the program with an error, rather than
apparently compiling it successfully, but producing a program that gives
incorrect results at runtime.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gcc 4:9.3.0-1ubuntu2
ProcVersionSignature: Ubuntu 5.4.0-91.102-generic 5.4.151
Uname: Linux 5.4.0-91-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: X-Cinnamon
Date: Sun Dec 12 17:01:45 2021
InstallationDate: Installed on 2019-11-11 (761 days ago)
InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805)
SourcePackage: gcc-defaults
UpgradeStatus: Upgraded to focal on 2020-10-02 (436 days ago)

** Affects: gcc-defaults (Ubuntu)
     Importance: Undecided
         Status: New

** Tags: amd64 apport-bug focal third-party-packages

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-defaults in Ubuntu.
https://bugs.launchpad.net/bugs/1954598

Title:
  gcc ignores large _Alignas specifiers on static .bss data

Status in gcc-defaults package in Ubuntu:
  New

Bug description:
  Instructions to reproduce: compile the following C program:
  ```
  #include <stdio.h>

  static _Alignas(4 << 20) int x;

  int main(void) {
      printf("%#llx\n", (long long) &x);
      return 0;
  }
  ```

  using `gcc` with no arguments other than the program's filename (which
  must end `.c` so that gcc interprets it as a C program), and run the
  resulting a.out.

  Expected behaviour: the program prints a number that's divisible by
  2²² (in hexadecimal, the resulting number will end with five zeroes,
  and the preceding digit will be divisible by 4).

  Actual behaviour: the program prints an arbitrary number that's
  divisible by 2¹², but which is normally not divisible by 2²². (The
  exact number varies between runs of the program; some example observed
  values include 0x55c2be889000 and 0x55d2cd348000.)

  This bug seems to be somehow specific to the way Ubuntu has configured
  `gcc` – it doesn't show up on a Red Hat-based Linux system, or when
  compiling using `clang`. As far as I can tell, the bug isn't in the
  compiler portion of `gcc`, but rather in the driver process; something
  in the arguments that it's passing to the linker is causing this
  behaviour.

  I suspect that the bug is related to position independent code. (In
  particular, compiling with `gcc -fno-pie` will cause an error along
  the line of `/usr/bin/ld: /tmp/cc6nztmN.o: relocation R_X86_64_32
  against `.bss' can not be used when making a PIE object; recompile
  with -fPIE`, rather than linking successfully, which means that the
  linker has been told by the compiler to make a position-independent
  executable even when the user explicitly tells it not to.)

  It is possible that this misbehaviour has been introduced
  intentionally for security reasons (because requiring a large
  alignment for the program image reduces the amount of security that
  address space layout randomization can provide). However, in this
  case, I think the correct behaviour should be to reject the program
  with an error, rather than apparently compiling it successfully, but
  producing a program that gives incorrect results at runtime.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: gcc 4:9.3.0-1ubuntu2
  ProcVersionSignature: Ubuntu 5.4.0-91.102-generic 5.4.151
  Uname: Linux 5.4.0-91-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: X-Cinnamon
  Date: Sun Dec 12 17:01:45 2021
  InstallationDate: Installed on 2019-11-11 (761 days ago)
  InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805)
  SourcePackage: gcc-defaults
  UpgradeStatus: Upgraded to focal on 2020-10-02 (436 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1954598/+subscriptions