Bug#1071378: linux-image-6.7.12-686-pae: Crash during early boot

[Jörn Heusipp]

Hello !


and should also end up back-ported in 6.9.5:
  https://lore.kernel.org/all/20240616133543.1590007-1-osm...@heusipp.de/


Thanks for the notification. So this will end in our next upload based
on at least 6.9.5.


Looks like it just missed 6.9.5. Hopefully it will be in 6.9.6 then.

Regards,
Jörn

Bug#1071378: linux-image-6.7.12-686-pae: Crash during early boot

[Jörn Heusipp]

This is fixed in upstream 6.10:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.10-rc3&id=2a38e4ca302280fdcce370ba2bee79bac16c4587

and should also end up back-ported in 6.9.5:
 https://lore.kernel.org/all/20240616133543.1590007-1-osm...@heusipp.de/

Regards,
Jörn

Bug#1071378: [REGRESSION] commit fbf6449f84bf5e4ad09f2c09ee70ed7d629b5ff6 (Linux 6.7+) crashes during boot

[Jörn Heusipp]

Hello!

On 30/05/2024 09:27, Linux regression tracking (Thorsten Leemhuis) wrote:

On 30.05.24 08:55, Jörn Heusipp wrote:



commit fbf6449f84bf5e4ad09f2c09ee70ed7d629b5ff6 ("x86/sev-es: Set
x86_virt_bits to the correct value straight away, instead of a two-phase
approach") crashes during boot for me on this 32bit x86 system.


FWIW, not my area of expertise, but there is a patch from Dave with a
Fixes: tag for your culprit up for review:
https://lore.kernel.org/all/20240517200534.8ec5f...@davehans-spike.ostc.intel.com/


That did not apply cleanly to 6.10-rc1, but I figured it out manually. I
can confirm that it fixes the issue.

Best regards,
Jörn

Bug#1071378: [REGRESSION] commit fbf6449f84bf5e4ad09f2c09ee70ed7d629b5ff6 (Linux 6.7+) crashes during boot

[Jörn Heusipp]

Hello x86 maintainers!


commit fbf6449f84bf5e4ad09f2c09ee70ed7d629b5ff6 ("x86/sev-es: Set
x86_virt_bits to the correct value straight away, instead of a two-phase
approach") crashes during boot for me on this 32bit x86 system.

Updating a Debian testing system resulted in a hang during boot before
printing anything, with any 6.7 or later kernel. With 'earlyprintk=vga',
I managed to capture the crash on video and stitched it together as an
image [1].
Trimmed transcription (might contain typos) of the crash from Debian
kernel 6.7.12-1:
===
BUG: kernel NULL pointer dereference, address: 0010
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
Oops: 0002 [#1] PREEMPT SMP NOPTI
[...]
EIP: __ring_buffer_alloc+0x32/0x194
[...]
show_regs
__die
page_fault_oops
kernelmode_fixup_or_oops.constprop
__bad_area_nosemaphore.constprop
bad_area_nosemaphore
do_user_addr_fault
prb_read_valid
exc_page_fault
pvclock_clocksource_read_nowd
handle_exception
pvclock_clocksource_read_nowd
__ring_buffer_alloc
pvclock_clocksource_read_nowd
__ring_buffer_alloc
early_trace_init
start_kernel
i386_start_kernel
startup_32_smp
[...]
===
I could transcribe all of it or capture it again from latest git and
decode the symbols, if truely really needed, but I figured the type of
crash and the trace itself could maybe be sufficient. It looks identical
to me for all later crashing kernel versions.

I bisected this down to commit fbf6449f84bf5e4ad09f2c09ee70ed7d629b5ff6.

The kernel config [2] I used is 'make olddefconfig' based on Debian's
config-6.8.11-686-pae [3].

I also tested 6.9.2 and 6.10-rc1, both also still crash in the same way.

cpuinfo:
===
manx@caesar:~$ cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 8
model name  : AMD Duron(tm)
stepping: 1
cpu MHz : 1798.331
cache size  : 64 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow cpuid
3dnowprefetch vmmcall
bugs: fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2
spec_store_bypass
bogomips: 3596.66
clflush size: 32
cache_alignment : 32
address sizes   : 34 bits physical, 32 bits virtual
power management: ts
===

dmesg from a successful boot (Debian kernel 6.6.15-2) is here [4].

This particular system has been running all Debian testing kernels since
at least the 2.6.32 days and is currently running 6.6.15-2 completely
fine, thus this is an obvious regression.

The original Debian bug is #1071378 [5].


#regzbot introduced: fbf6449f84bf5e4ad09f2c09ee70ed7d629b5ff6

[1] https://manx.datengang.de/temp/linux-6.7-crash/6.7.12-1-crash.png
[2] https://manx.datengang.de/temp/linux-6.7-crash/config
[3] https://manx.datengang.de/temp/linux-6.7-crash/config-6.8.11-686-pae
[4] https://manx.datengang.de/temp/linux-6.7-crash/dmesg-6.6.15-2.txt
[5] https://bugs.debian.org/1071378


Best regards,
Jörn

Bug#1071378: linux-image-6.7.12-686-pae: Crash during early boot

[Jörn Heusipp]

Hello!


I cannot reproduce this problem.


So it might be probably somewhat system-specific. I have not tried other 
i386 systems myself.



If you still can with the recent
6.8.11-1 landed in unstable,


6.8.11-1 also crashes.


you might try to bisect the changes in
upstream kernel to determine the breaking commit?


I'll try to do that, but it might take a couple of days until I have a 
result.


Should I report the bug upstream myself or will Debian handle this?

Regards,
Jörn

Bug#1028580: gcc-mingw-w64: i686-w64-mingw32-gcc reports wrong version in __GNUC__ __GNUC_MINOR__ __GNUC_PATCHLEVEL__

[Jörn Heusipp]

Package: gcc-mingw-w64
Version: 12.2.0-14+25.2
Severity: normal
X-Debbugs-Cc: osm...@problemloesungsmaschine.de

Dear Maintainer,

i686-w64-mingw32-gcc reports wrong version in __GNUC__ __GNUC_MINOR__ 
__GNUC_PATCHLEVEL__.

The package has version 12.2.0-14+25.2, while GCC itself reports itself as 
12.0.0.
Native GCC behaves correctly.

```
manx@appendix:~/tmp$ cat foo.c
#include 
int main() {
printf("%i.%i.%i\n", __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__);
}
manx@appendix:~/tmp$ i686-w64-mingw32-gcc -std=c17 -O3 -Wall -Wextra -Wpedantic 
foo.c
manx@appendix:~/tmp$ ./a.exe
0080:err:winediag:nodrv_CreateWindow Application tried to create a window, but 
no driver could be loaded.
0080:err:winediag:nodrv_CreateWindow Make sure that your X server is running 
and that $DISPLAY is set correctly.
0080:err:systray:initialize_systray Could not create tray window
12.0.0
manx@appendix:~/tmp$ gcc -std=c17 -O3 -Wall -Wextra -Wpedantic foo.c
manx@appendix:~/tmp$ ./a.out
12.2.0
manx@appendix:~/tmp$ i686-w64-mingw32-gcc-posix --version
i686-w64-mingw32-gcc-posix (GCC) 12-posix
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, s390x, armhf, arm64, ppc64el

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-mingw-w64 depends on:
ii  gcc-mingw-w64-i68612.2.0-14+25.2
ii  gcc-mingw-w64-x86-64  12.2.0-14+25.2

gcc-mingw-w64 recommends no packages.

gcc-mingw-w64 suggests no packages.

-- no debconf information

Bug#1014177: qemu-user-static: QEMU aarch64 user mode emulation always segfaults

[Jörn Heusipp]

Package: qemu-user-static
Version: 1:7.0+dfsg-7
Severity: important
X-Debbugs-Cc: osm...@problemloesungsmaschine.de

Dear Maintainer,

I am using QEMU user mode emulation to test my software on non-amd64 
architectures. I have qemu-user-static and binfmt-support installed so that I 
can run foreign binaries seamlessly.

On Debian Testing with QEMU 7, aarch64 user mode emulation always segfaults:
```
manx@appendix:~/tmp$ cat nothing.c
int main() {
return 0;
}
manx@appendix:~/tmp$ aarch64-linux-gnu-gcc -std=c18 -O3 -Wall -Wextra 
-Wpedantic nothing.c
manx@appendix:~/tmp$ ./a.out
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
manx@appendix:~/tmp$
```

Other architectures like s390x work fine:
```
manx@appendix:~/tmp$ s390x-linux-gnu-gcc -std=c18 -O3 -Wall -Wextra -Wpedantic 
nothing.c
manx@appendix:~/tmp$ ./a.out
manx@appendix:~/tmp$
```

Static linking does not help:
```
manx@appendix:~/tmp$ aarch64-linux-gnu-gcc -std=c18 -O3 -Wall -Wextra 
-Wpedantic -static nothing.c
manx@appendix:~/tmp$ ./a.out
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
manx@appendix:~/tmp$
```

relevant versions:
```
manx@appendix:~/tmp$ aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (Debian 11.3.0-3) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
manx@appendix:~/tmp$ qemu-aarch64-static --version
qemu-aarch64 version 7.0.0 (Debian 1:7.0+dfsg-7)
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
manx@appendix:~/tmp$
```

QEMU aarch64 user mode emulation works fine on Debian 11 Bullseye with QEMU 5.2.

Thanks,
Jörn


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, s390x, armhf, arm64, ppc64el

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.2.2-1
ii  systemd 251.2-7

qemu-user-static suggests no packages.

-- no debconf information

Bug#1003382: g++-mingw-w64-x86-64-posix: g++-mingw-w64-posix fails to set __STDCPP_THREADS__=1 even though it supports std::thread

[Jörn Heusipp]

Package: g++-mingw-w64-x86-64-posix
Version: 10.2.1-6+24.2
Severity: normal
X-Debbugs-Cc: osm...@problemloesungsmaschine.de

Dear Maintainer,

Consider the following C++ program:
```
#if defined(__STDCPP_THREADS__) && (__STDCPP_THREADS__ == 1)

#include 
#include 

#include 

static void mythread(double param) {
double value = std::pow(param, param);
std::cout << value << std::endl;
return;
}

bool test(int param) {
{
std::thread t{&mythread, static_cast(param)};
t.join();
}
return true;
}

int main(int argc, const char * argv []) {
static_cast(argv);
return test(argc) ? 1 : 0;
}

#else

#error "no threads"

#endif
```

I am seeing:
```
manx@appendix:~/tmp$ x86_64-w64-mingw32-g++-posix -std=c++17 -O3 -Wall -Wextra 
-Wpedantic -mthreads cxx17.cpp -o test
cxx17.cpp:30:2: error: #error "no threads"
   30 | #error "no threads"
  |  ^
```

However, when I manually set -D__STDCPP_THREADS__=1, it builds just fine. The 
resulting binary also runs fine on Windows.
```
manx@appendix:~/tmp$ x86_64-w64-mingw32-g++-posix -std=c++17 -O3 -Wall -Wextra 
-Wpedantic -mthreads -D__STDCPP_THREADS__=1 cxx17.cpp -o test
manx@appendix:~/tmp$
```

The C++ standard requires compliant implementations to set __STDCPP_THREADS__=1 
when they provide , std::thread, and threading support in general.

The internal _GLIBCXX_HAS_GTHREADS is defined (after including a standard 
library header).

Upstream told me in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949#c5 that 
this would be a GCC configuration error, and that GCC needs to be built 
differently. I am not knowledgable enough about GCC internals to make that 
call. As I understand it, this configuration ought to be blocked by upstream 
from even be buildable at all, as it very obviously contradicts itself and is 
confused about whether it supports threads or not.

In any case, can you please build MinGW-w64 GCC in a way so that the version 
with POSIX threading model properly sets __STDCPP_THREADS__=1 ?

If you agree with my assertion of this being an upstream bug, could you also 
please report it upstream? I feel a bug coming from Debian would have more 
influence on upstream than a bug report from only a user.

As already said, I am not an expert in GCC internals. What are the implications 
of the current supposed misconfiguration on the implemenation of C++11 
threadsafe-statics? Does GCC not being properly thread-aware introduce an 
initialization race?



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, s390x, armhf, arm64, ppc64el

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages g++-mingw-w64-x86-64-posix depends on:
ii  gcc-mingw-w64-base  10.2.1-6+24.2
ii  gcc-mingw-w64-x86-64-posix  10.2.1-6+24.2
ii  gcc-mingw-w64-x86-64-posix-runtime  10.2.1-6+24.2
ii  libc6   2.33-1
ii  libgcc-s1   11.2.0-13
ii  libgmp102:6.2.1+dfsg-3
ii  libisl230.24-2
ii  libmpc3 1.2.1-1
ii  libmpfr64.1.0-3
ii  libstdc++6  11.2.0-13
ii  zlib1g  1:1.2.11.dfsg-2

g++-mingw-w64-x86-64-posix recommends no packages.

Versions of packages g++-mingw-w64-x86-64-posix suggests:
pn  gcc-10-locales  

-- no debconf information

Bug#995965: containerd dies with Illegal Instruction when run on a pre-SSE2-class x86 system

[Jörn Heusipp]

Hi!


It's same. And I have requested the release team to rebuild all Go packages on
i386.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995946


Sorry, I was not aware of that bug report. That should solve it indeed.

Thanks,
Jörn

Bug#995965: containerd dies with Illegal Instruction when run on a pre-SSE2-class x86 system

[Jörn Heusipp]

Package: containerd
Version: 1.5.7~ds1-1
Severity: important
X-Debbugs-Cc: osm...@problemloesungsmaschine.de

Dear Maintainer,

Starting containerd results in Illegal Instruction on a 32bit x86 system.

Looking at the core dump with gdb shows the offending instruction as
0x808ef13   movsd  %xmm0,0x44(%esp) 
.
This is an SSE2 instruction, however, my CPU only supports SSE1.

As containerd is written in Go, this is likely due to
, thus building with GO386=softfloat
might fix the issue.

See related bug report on dockerd (#995708).

Thanks,
Jörn


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 5.14.0-1-686-pae (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages containerd depends on:
ii  libc6  2.32-4
ii  runc   1.0.2+ds1-1

containerd recommends no packages.

Versions of packages containerd suggests:
pn  containernetworking-plugins  

-- no debconf information

Bug#995708: docker.io: dockerd dies with Illegal Instruction when run on a pre-SSE2-class x86 system

[Jörn Heusipp]

I am by no means a Go expert, however given that docker is written in 
Go, and that Go increased the default i386 architecture requirements to 
SSE2 in 1.16 (see ), building the 
docker package with GO386=softfloat on i386 might solve this issue. The 
set of x86 CPUs supporting SSE2 but not also supporting amd64 is quite 
small. Basically, only the Pentium 4. Thus to be useful on 32bit x86 
systems in general, I think wider compatibility, even at a performance 
cost, could be considered.


Thanks,
Jörn

Bug#995708: docker.io: dockerd dies with Illegal Instruction when run on a pre-SSE2-class x86 system

[Jörn Heusipp]

Package: docker.io
Version: 20.10.8+dfsg1-1
Severity: important
X-Debbugs-Cc: osm...@problemloesungsmaschine.de

Dear Maintainer,

Starting dockerd results in Illegal Instruction on a 32bit x86 system.

Looking at the core dump with gdb shows the offending instruction as
 >0x8ece78movsd  xmm0,QWORD PTR [eax]
(with eax containing 0x23fdc64).

This is 'Move Scalar Double-Precision Floating-Point Value', which is an SSE2 
instruction. SSE1 only supports single precision floating point.

The CPU in question here is an AMD Duron 1800, which supports SSE, but not SSE2.

As this CPU is still supported by Debian and will be (as far as I know) for the 
next release, I would expect to be able to run docker on it.

root@caesar:~# cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 8
model name  : AMD Duron(tm)
stepping: 1
cpu MHz : 1798.276
cache size  : 64 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall
bugs: fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 
spec_store_bypass
bogomips: 3596.55
clflush size: 32
cache_alignment : 32
address sizes   : 34 bits physical, 32 bits virtual
power management: ts


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 5.14.0-1-686-pae (SMP w/1 CPU thread)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages docker.io depends on:
ii  adduser  3.118
ii  containerd   1.5.5~ds1-1
ii  dpkg 1.20.9
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.32-4
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libsystemd0  247.9-1
ii  lsb-base 11.1.0
ii  runc 1.0.2+ds1-1
ii  tini 0.19.0-1

Versions of packages docker.io recommends:
ii  apparmor 3.0.3-2
ii  ca-certificates  20210119
ii  cgroupfs-mount   1.4
ii  git  1:2.33.0-1
ii  needrestart  3.5-4
ii  xz-utils 5.2.5-2

Versions of packages docker.io suggests:
pn  aufs-tools   
ii  btrfs-progs  5.14.1-1
ii  debootstrap  1.0.123
pn  docker-doc   
ii  e2fsprogs1.46.4-1
pn  rinse
ii  rootlesskit  0.14.2-1+b3
ii  xfsprogs 5.13.0-1
ii  zfs-fuse 0.7.0-22

-- no debconf information

Bug#989956: libopenmpt: new upstream release branch 0.5

[Jörn Heusipp]

Source: libopenmpt
Version: 0.4.11
Severity: wishlist
X-Debbugs-Cc: osm...@problemloesungsmaschine.de

Dear Maintainer,

Updating to libopenmpt 0.5 will involve changes in packaging because we 
(libopenmpt upstream) have split out the libopenmpt-modplug emulation layer 
into a completely separate upsteam package. See 
,
 
,
 . 
In the end, this will simplify future updates to libopenmpt-modplug, because we 
can now follow libmodplug API and ABI changes more closely and independently of 
libopenmpt versions and API/ABI guarantees.

Updating to libopenmpt 0.5 and libopenmpt-modplug 0.8.9.0-openmpt1 (same ABI 
change as in the matching libmodplug version) will also fix #958377.

If you encounter any problems updating, or have suggestions which we can 
integrate to make packaging and updating easier, please feel free to contact me.


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, s390x, armhf, arm64, ppc64el

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#989955: libopenmpt: new upstream release 0.4.21

[Jörn Heusipp]

Source: libopenmpt
Version: 0.4.11
Severity: important
X-Debbugs-Cc: osm...@problemloesungsmaschine.de

Dear Maintainer,

libopenmpt 0.4.x has new upstream release 0.4.21. This fixes, amongst many 
other fixes, a security vulnerability:
https://lib.openmpt.org/libopenmpt/2021/04/11/security-updates-0.5.8-0.4.20-0.3.29/

I'm the libopenmpt upstream maintainer. If you encounter any problems updating, 
please feel free to contact me and ask for assistence.

Seeing that Debian 11 is going into freeze soon, I highly suggest updating to 
the latest libopenmpt version now.

If updating to 0.5 causes too much trouble by now, updating to at least 0.4.21 
should be trivial. Even though libopenmpt deprecated the included 
libopenmpt-modplug emulation layer in 0.4.13 (see 
), 
0.4.x still continues (and will continue) to ship it (staying with libmodplug 
0.8.8.5 API/ABI).

Updating to 0.5 and the split-out libopenmpt-modplug package will be required 
to fix #958377 though, which appears to be desireable to support VLC.


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, s390x, armhf, arm64, ppc64el

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#989952: libopenmpt: missing security patches (r12118, r14531) in stable

[Jörn Heusipp]

Source: libopenmpt
Version: 0.4.3
Severity: normal
Tags: upstream
X-Debbugs-Cc: osm...@problemloesungsmaschine.de

Dear Maintainer,

It looks like libopenmpt in Debian 10 Buster (stable) is missing patches for 
the following security vulnerabilities:

libopenmpt 0.4.8 (2019-09-30)
[Sec] Possible crash due to out-of-bounds read when playing an OPL note 
with active filter in S3M or MPTM files (r12118).
https://source.openmpt.org/browse/openmpt?op=comp&compare[]=%2Fbranches%2FOpenMPT-1.28@12116&compare[]=%2Fbranches%2FOpenMPT-1.28%2F@12118
https://github.com/OpenMPT/openmpt/commit/5b6503eeb35ae41e496a23640c7750351e808ea7

libopenmpt 0.4.20 (2021-04-11)
[Sec] Possible null-pointer dereference read caused by a sequence of 
openmpt::module::read, openmpt::module::set_position_order_row pointing to an 
invalid pattern, and another openmpt::module::read call. To trigger the crash, 
pattern 0 must not exist in the file and the tick speed before the position 
jump must be lower than the initial speed of the module. (r14531)
https://source.openmpt.org/browse/openmpt?op=comp&compare[]=%2Fbranches%2FOpenMPT-1.28@14520&compare[]=%2Fbranches%2FOpenMPT-1.28%2F@14531
https://github.com/OpenMPT/openmpt/commit/b6f4b8a731576b77afc2cc73441991e110a72252

If you encounter any trouble or problems backporting the fixes to 0.4.3, please 
feel free to ask for help, as I am the libopenmpt upstream maintainer.


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, s390x, armhf, arm64, ppc64el

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#867579: Acknowledgement (libopenmpt: Security updates libopenmpt-0.2.7386-beta20.3-p10 available)

[Jörn Heusipp]

tags -1 + security

Bug#867579: libopenmpt: Security updates libopenmpt-0.2.7386-beta20.3-p10 available

[Jörn Heusipp]

Source: libopenmpt
Version: 0.2.7386~beta20.3-3
Severity: important
Tags: upstream

Dear Maintainer,


A couple of security-related fixes have been released upstream as
version 0.2.7386-beta20.3-p10. See
https://lib.openmpt.org/libopenmpt/md_announce-2017-07-07.html .

p10 fixes a heap buffer overflow which allows an attacker to write
arbitrary data to an arbitrarily choosen offset. It can be triggered
with a maliciously modified PSM file. This needs to be fixed ASAP via
a security update in Stretch. The bug happens due to 2 samples in a
PSM file using the same sample slot in libopenmpt, whereby the second
sample uses an invalid offset inside the file. That way, the second
sample did not re-allocate (via
sampleHeader.GetSampleFormat().ReadSample(Samples[smp], file); deeper
down the call chain in SampleIO.cpp:73) the sample buffer itself but
only set the sample size metadata
(sampleHeader.ConvertToMPT(Samples[smp]);, ultimately at
Load_psm.cpp:1054). Later, as a loading post-processing step,
Sndfile.cpp:411 calls PrecomputeLoops() which writes a couple of
samples before and after the actual sample data (the amount is
statically known (InterpolationMaxLookahead) and accounted for when
allocating the sample buffer). However, due to the sample buffer and
sample length mismatch caused by the bug, this can write extrapolated
sample data to an arbitary location offset from the first sample's
buffer (PrecomputeLoopsImpl() in modsmp_ctrl.cpp:263).

p8 is an out-of-bounds read directly after a heap-allocated allocated
buffer. It is difficult to trigger in practice because std::vector
does grow its buffer exponentially.

p9 fixes another potential race condition due to the use of non
thread-safe  functions. As discussed previously in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864195#67 , this
again can at worst cause wrong data to be returned for date metadata
in libopenmpt. However, please note that the same, now rewritten code
path, could also trigger an assertion failure in glibc under memory
pressure (which probably is a glibc bug, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867283 ), thereby
causing the application to crash.


-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#864195: closed by James Cowgill (Bug#864195: fixed in libopenmpt 0.2.8190~beta24-1)

[Jörn Heusipp]

On 06/19/2017 08:45 PM, Debian Bug Tracking System wrote:

#864195: libopenmpt: Security updates libopenmpt-0.2.7386-beta20.3-p7 available
It has been closed by James Cowgill .


As far as I can see, there is still no updated libopenmpt package in 
Stretch for any of the issues.


Jörn

Bug#865407: wine-development: Wine cannot execute position-independent (PIE) host executables via CreateProcess()

[Jörn Heusipp]

Script and source to reproduce attached.
#include 
int main() {
fprintf(stderr, "%s\n", "Hello World!");
return 0;
}


script.sh
Description: application/shellscript
#include 
#include 
#include 
int main() {
	STARTUPINFO startupInfo;
	ZeroMemory(&startupInfo, sizeof(STARTUPINFO));
	startupInfo.lpTitle = "dummy";
	startupInfo.cb = sizeof(startupInfo);
	PROCESS_INFORMATION processInformation;
	ZeroMemory(&processInformation, sizeof(PROCESS_INFORMATION));
	if(CreateProcess(NULL, "./hello", NULL, NULL, FALSE, CREATE_NEW_CONSOLE, NULL, NULL, &startupInfo, &processInformation) == FALSE) {
		fprintf(stderr, "CreateProcess() failed\n");
		return 1;
	}
	WaitForSingleObject(processInformation.hProcess, INFINITE);
	CloseHandle(processInformation.hThread);
	CloseHandle(processInformation.hProcess);
	return 0;
}

Bug#865407: wine-development: Wine cannot execute position-independent (PIE) host executables via CreateProcess()

[Jörn Heusipp]

Package: wine-development
Version: 2.0-3
Severity: normal
Tags: upstream

Dear Maintainer,


Wine cannot execute position-independent (PIE) host executables via 
CreateProcess()

The problem arises from the fact that `create_process_impl()` in
`dlls/kernel32/process.c` ultimately calls `MODULE_get_binary_info()`
in `dlls/kernel32/module.c` which detects PIE exectuables as ELF
shared objects and thus sets `info->type = BINARY_UNIX_LIB;` instead of
`info->type = BINARY_UNIX_EXE;`. I do not have enough knowledge about
the precise way that Winelib apps are implemented or supposed to work,
but the fact that PIE executables are in fact ELF shared objects and
not ELF executables according to the ELF header, causes Wine to detect
these as Winelib apps and ultimately invoke the wrong process creation
path.

As Debian 9 Stretch switched to PIE by default, this basically affects
all native executables. Non-PIE executables work fine.

Wine 1.8.7 is also affected, as is the current Wine development branch.

Upstream bug report is at https://bugs.winehq.org/show_bug.cgi?id=43217 .

```
manx@vmdebian9:~/test$ ./script.sh 
+ cat script.sh
#!/usr/bin/env bash
set -x
cat script.sh
cat hello.c
cat test.c
x86_64-w64-mingw32-gcc -mconsole -std=c99 -O2 -Wall -Wextra test.c -o test.exe
gcc -no-pie -fno-PIE -std=c99 -O2 -Wall -Wextra hello.c -o hello
file hello
wine64-development test.exe
WINEDEBUG=trace+process wine64-development test.exe
gcc -pie -fPIE -std=c99 -O2 -Wall -Wextra hello.c -o hello
file hello
wine64-development test.exe
WINEDEBUG=trace+process wine64-development test.exe
uname -m
cat /etc/debian_version
gcc -dumpversion
wine64-development --version

+ cat hello.c
#include 
int main() {
fprintf(stderr, "%s\n", "Hello World!");
return 0;
}
+ cat test.c
#include 
#include 
#include 
int main() {
STARTUPINFO startupInfo;
ZeroMemory(&startupInfo, sizeof(STARTUPINFO));
startupInfo.lpTitle = "dummy";
startupInfo.cb = sizeof(startupInfo);
PROCESS_INFORMATION processInformation;
ZeroMemory(&processInformation, sizeof(PROCESS_INFORMATION));
if(CreateProcess(NULL, "./hello", NULL, NULL, FALSE, 
CREATE_NEW_CONSOLE, NULL, NULL, &startupInfo, &processInformation) == FALSE) {
fprintf(stderr, "CreateProcess() failed\n");
return 1;
}
WaitForSingleObject(processInformation.hProcess, INFINITE);
CloseHandle(processInformation.hThread);
CloseHandle(processInformation.hProcess);
return 0;
}

+ x86_64-w64-mingw32-gcc -mconsole -std=c99 -O2 -Wall -Wextra test.c -o test.exe
+ gcc -no-pie -fno-PIE -std=c99 -O2 -Wall -Wextra hello.c -o hello
+ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, 
interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, 
BuildID[sha1]=db69604025be8ad94f0f8d80e9c60eff185a8b07, not stripped
+ wine64-development test.exe
Hello World!
+ WINEDEBUG=trace+process
+ wine64-development test.exe
trace:process:init_current_directory starting in L"Z:\\home\\manx\\test\\" 0x8
trace:process:__wine_kernel_init starting process 
name=L"Z:\\home\\manx\\test\\test.exe" argv[0]=L"Z:\\home\\manx\\test\\test.exe"
trace:process:create_process_impl app (null) cmdline L"./hello"
trace:process:find_exe_file looking for L"./hello"
trace:process:find_exe_file Trying native exe L"Z:\\home\\manx\\test\\hello"
trace:process:create_process_impl starting L"Z:\\home\\manx\\test\\hello" as 
Unix binary
trace:process:create_process_impl started process pid  tid 
Hello World!
+ gcc -pie -fPIE -std=c99 -O2 -Wall -Wextra hello.c -o hello
+ file hello
hello: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically 
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, 
BuildID[sha1]=e002ea7db0a5e5223085e78d97a6f25f61160958, not stripped
+ wine64-development test.exe
wine: Bad EXE format for Z:\home\manx\test\hello..
CreateProcess() failed
+ WINEDEBUG=trace+process
+ wine64-development test.exe
trace:process:init_current_directory starting in L"Z:\\home\\manx\\test\\" 0x8
trace:process:__wine_kernel_init starting process 
name=L"Z:\\home\\manx\\test\\test.exe" argv[0]=L"Z:\\home\\manx\\test\\test.exe"
trace:process:create_process_impl app (null) cmdline L"./hello"
trace:process:find_exe_file looking for L"./hello"
trace:process:find_exe_file Trying native exe L"Z:\\home\\manx\\test\\hello"
trace:process:create_process_impl starting L"Z:\\home\\manx\\test\\hello" as 
64-bit Winelib app
trace:process:init_current_directory starting in L"Z:\\home\\manx\\test\\" 0xc
trace:process:__wine_kernel_init starting process 
name=L"Z:\\home\\manx\\test\\hello." argv[0]=L"./hello"
wine: Bad EXE format for Z:\home\manx\test\hello..
CreateProcess() failed
+ uname -m
x86_64
+ cat /etc/debian_version
9.0
+ gcc -dumpversion
6.3.0
+ wine64-development --version
wine-2.0 (Debian 2.0-3+b2)
manx@vmdebian9:~/test$ 
```


-- Package-specific info:
/usr/bin/win

Bug#864195: libopenmpt: Security updates libopenmpt-0.2.7386-beta20.3-p7 available

[Jörn Heusipp]

Hi,

On 06/07/2017 11:45 AM, James Cowgill wrote:

On 05/06/17 07:03, Jörn Heusipp wrote:



A couple of security-related fixes have been released upstream as
version 0.2.7386-beta20.3-p7. See
https://lib.openmpt.org/libopenmpt/md_announce-2017-06-02.html

These most importantly fix a couple of possible crashes which can be
triggered by maliciously modified or malformed or truncated module
files as well as denial-of-service through hangs or excessive CPU
consumption which can also be triggered maliciously modfied or
malformed or truncated module files.


I've had a look at the patches now and this is what I think:

p1-division-by-zero-in-tempo-calculation.patch
p2-infinite-loop-in-plugin-routing.patch
p6-invalid-memory-read-when-applying-nnas-to-effect-plugins.patch

These three are clearly denial-of-service by malicious module file and
should be fixed in stretch. However, I don't think the first two are
"serious" because they're just denial-of-service bugs in a library
almost exclusively used on end user machines (as opposed to eg remote
code execution).


Agreed.


I don't understand patch p6 well enough to say how
serious it is (depends on where the invalid pointer being dereferenced
comes from).


As far as I know, it is just a NULL pointer. Johannes did the analysis 
and might be able to elaborate (CCed).



p3-excessive-cpu-consumption-on-malformed-files-dmf-mdl.patch
p5-excessive-cpu-consumption-on-malformed-files-ams.patch

Are these actually security bugs? As long as the code finishes in a
reasonable amount of time and produces the right results, then there's
not much harm in leaving the code as it is.


Again, Johannes knows more about these.


p4-theoretical-null-pointer-dereference-during-out-of-memory-while-error-handling.patch


[...]


I also note that the C++ standard _requires_ std::exception::what to
return a non-null value so a very intelligent compiler could
legitimately remove the null check (I doubt GCC does this though).


Correct, I had realized that too late. I had originally triggered that 
when testing corner cases in error handling, but it can indeed only 
happen if other code does not behave correctly and returns nullptr from 
std::exception::what. openmpt::exception::what in 0.2.7386-beta20.3 
returns a static string as a fallback and cannot trigger it either.



p7-race-condition-in-multi-threaded-use-it.patch

I also don't think this is a security bug (at least on Linux). Looking
at the glibc sources, the internal tzdata state is protected by a mutex
so the only risk here is that localtime will return some garbage time
values. Since the string generated by this function is only going to be
shown to the user, nothing that bad will happen in this case.


Yes, if glibc uses a mutex internally (I was not aware of that), the 
worst case outcome is indeed only a wrong string getting returned.



Finally,
it relies on a multithreaded client application loading 2 modules at the
same time which seems unlikely to me.


Or any other concurrent call to localtime(). Which is also unlikely.

Jörn

Bug#864195: libopenmpt: Security updates libopenmpt-0.2.7386-beta20.3-p7 available

[Jörn Heusipp]

Source: libopenmpt
Version: 0.2.7386~beta20.3-3
Severity: important
Tags: upstream

Dear Maintainer,

A couple of security-related fixes have been released upstream as version 
0.2.7386-beta20.3-p7. See 
https://lib.openmpt.org/libopenmpt/md_announce-2017-06-02.html .
These most importantly fix a couple of possible crashes which can be triggered 
by maliciously modified or malformed or truncated module files as well as 
denial-of-service through hangs or excessive CPU consumption which can also be 
triggered maliciously modfied or malformed or truncated module files.


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)