Bug#1034548: bullseye-pu: package glibc/2.31-13+deb11u6

[Aurelien Jarno]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: gl...@packages.debian.org, debian-boot@lists.debian.org, 
debian-gl...@lists.debian.org
Control: affects -1 + src:glibc

[ Reason ]
There are multiple fixes in this upload, all coming from the upstream
stable branch:
- Multiple crashes or memory leak in printf-family functions
- Overflow fix in the AVX2 implementation of wcsnlen

[ Impact ]
In case the update isn't approved, systems will be left with issues
which combined with other vulnerabilities might lead to denial of
service.

[ Tests ]
The upstream fixes come with additional tests, which represent a
significant part of the diff.

[ Risks ]
The most risky parts are probably the printf-family functions changes,
however those changes are in testing/sid for ~1.5 years (since glibc
2.32), but have only been identified as problematic recently. The
wcsnlen fix is in testing/sid for ~4 months. All of those changes come
with additional tests.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Let me comment the changelog:

 - Drop debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
   (obsolete).

The upstream stable branch for glibc 2.31 now includes the fix
introduced in glibc 2.31-13+deb11u5 to fix some crash on some CPU.
Therefore this patch is not needed anymore.

 - Fix memory leak in printf-family functions with long multibyte strings.

   This fixes a memory leak that might lead to OOM when calling with
   long multibyte strings. The simplest reproducer is:
 printf("%.1371337ls", L"A\n");

 - Fix a crash in printf-family due to width/precision-dependent
   allocations.

   This fixes a crash due to a missing overflow check in the requested
   precision. The simplest reproducer is:
 fprintf (fp, "%2$.*1$a", 0x7fff, 1e200);

 - Fix a segfault in printf handling thousands separator.

   This segmentation fault has been fixed as a side effect of the
   previous fix, but comes with a specific test. The simplest reproducer
   is:
 setlocale(LC_ALL, "en_US.UTF-8");
 printf("%'1000d\n", 1000);

 - Fix an overflow in the AVX2 implementation of wcsnlen when crossing
   pages.

   The overflow happens when wcsnlen is called with a huge maxlen
   argument (e.g. (1UL << 63)), triggering an assertion in the wcsnlen
   code.
diff --git a/debian/changelog b/debian/changelog
index 50f6135b..3d95edf8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+glibc (2.31-13+deb11u6) UNRELEASED; urgency=medium
+
+  [ Aurelien Jarno ]
+  * debian/patches/git-updates.diff: update from upstream stable branch:
+- Drop debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
+  (obsolete).
+- Fix memory leak in printf-family functions with long multibyte strings.
+- Fix a crash in printf-family due to width/precision-dependent
+  allocations.
+- Fix a segfault in printf handling thousands separator.
+- Fix an overflow in the AVX2 implementation of wcsnlen when crossing
+  pages.
+
+ -- Aurelien Jarno   Sun, 16 Apr 2023 18:58:33 +0200
+
 glibc (2.31-13+deb11u5) bullseye; urgency=medium
 
   * debian/patches/local-require-bmi-in-avx2-ifunc.diff: new patch extracted
diff --git a/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff 
b/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
deleted file mode 100644
index 936f89ae..
--- a/debian/patches/amd64/local-require-bmi-in-avx2-ifunc.diff
+++ /dev/null
@@ -1,38 +0,0 @@
-This patch is extracted from upstream commit 83c5b368226c ("x86-64: Require
-BMI2 for strchr-avx2.S"). It changes the common ifunc AVX2 selector to require
-the BMI2 instructions, and the backported fixes for memchr and strlen rely on
-that change.
-
 a/sysdeps/x86_64/multiarch/ifunc-avx2.h
-+++ b/sysdeps/x86_64/multiarch/ifunc-avx2.h
-@@ -21,28 +21,28 @@ IFUNC_SELECTOR (void)
- 
- extern __typeof (REDIRECT_NAME) OPTIMIZE (sse2) attribute_hidden;
- extern __typeof (REDIRECT_NAME) OPTIMIZE (avx2) attribute_hidden;
- extern __typeof (REDIRECT_NAME) OPTIMIZE (avx2_rtm) attribute_hidden;
- extern __typeof (REDIRECT_NAME) OPTIMIZE (evex) attribute_hidden;
- 
- static inline void *
- IFUNC_SELECTOR (void)
- {
-   const struct cpu_features* cpu_features = __get_cpu_features ();
- 
-   if (CPU_FEATURES_ARCH_P (cpu_features, AVX2_Usable)
-+  && CPU_FEATURES_CPU_P (cpu_features, BMI2)
-   && CPU_FEATURES_ARCH_P (cpu_features, AVX_Fast_Unaligned_Load))
- {
-   if (CPU_FEATURES_ARCH_P (cpu_features, AVX512VL_Usable)
--&& CPU_FEATURES_ARCH_P (cpu_features, AVX512BW_Usable)
--&& CPU_FEATURES_CPU_P (cpu_features, BMI2))
-+&& CPU_FEATURES_ARCH_P (cpu_features, AVX512BW_Usable))
-   return OPTIMIZE (evex);
- 
-   if 

Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Pascal Hambourg]

Control: reassign -1 hw-detect

On 17/04/2023 at 17:52, Cyril Brulebois wrote:

Pascal Hambourg  (2023-04-17):

Ugly attached patch works for me as PoC.
Copy fd 0 into fd 9 (because it looked unused) before entering the
pipeline, and restore it when running install_firmware_pkg.


I think I'd be happy to take this patch for bookworm, as a workaround…


Here is another patch for hw-detect moving the install_firmware_pkg()
call outside the pipeline instead of playing with file descriptors.


… before considering a real/better fix after bookworm.


Feel free to pick either patch you like. Both work for me.

To be fair, I searched if other firmware packages than firmware-ipw2x00 
had a preinst script using debconf dialog which required this fix, and 
the only other one I found is firmware-ivtv which is not related with 
networking or storage.



PS: shouldn't this bug report be reassigned to hw-detect ?


Where the bug comes from seems pretty clear by now, so feel free to
reassign, and maybe clone it so that we can track the workaround
(bookworm) and the fix (post-bookworm).


I've never cloned a bug report, so I'd rather leave it to a more 
experienced user.

Processed: Re: Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 hw-detect
Bug #1033921 [debian-installer] debian-installer: Weekly build of d-i fails to 
find ipw2x00 firmware package
Bug reassigned from package 'debian-installer' to 'hw-detect'.
Ignoring request to alter found versions of bug #1033921 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1033921 to the same values 
previously set

-- 
1033921: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033921
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Bug#1034535 marked as pending in debian-installer

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #1034535 [debian-installer] Installer boot menu displayed in text mode when 
UEFI secure boot is enabled
Added tag(s) pending.

-- 
1034535: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034535
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034535: Installer boot menu displayed in text mode when UEFI secure boot is enabled

[Pascal Hambourg]

Package: debian-installer
Severity: minor

Boot method: USB stick
Image version: debian-bookworm-DI-rc1-amd64-netinst.iso
Boot mode: UEFI

When secure boot is disabled, GRUB displays the menu in graphic mode as 
expected.

When secure boot is enabled, GRUB briefly displays error messages:

 prohibited by secure boot policy
 no video mode activated

and displays the menu in text mode.

This is caused by loadfont failing in /boot/grub/grub.cfg:

if loadfont $prefix/font.pf2 ; then
  set gfxmode=800x600
  set gfxpayload=keep
  insmod efi_gop
  insmod efi_uga
  insmod video_bochs
  insmod video_cirrus
  insmod gfxterm
  insmod png
  terminal_output gfxterm
fi

A recent change in grub prohibits loading fonts from outside the signed 
image, so loadfont was adapted to try and load the requested font from 
the embedded memdisk first instead of $prefix.


If I understand correctly, loadfont allows two types of arguments:
- a radix, which is expanded into $prefix/fonts/.pf2
- a pathname starting with / or (

The "magic" looking up (memdisk) first instead of $prefix works only 
with a radix whereas grub.cfg uses a full pathname. Also, it tries to 
load font.pf2 whereas the embedded font file is unicode.pf2.


I tested to replace "$prefix/font.pf2" with "unicode" or 
"(memdisk)/fonts/unicode.pf2" in /boot/grub/grub.cfg and the graphical 
menu was back. Actually, if I remove the loadfont command and the 'if' 
condition, as far as I can see the graphical menu is displayed 
correctly, except the border frame replaced by "?" in the menu entry 
editor, so maybe the condition could be removed.


PS: Maybe the issue also exists in live images ? Didn't check.

Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Isaac True (2023-04-17 10:49:20)
> > Why would you have to run flash-kernel again?
> 
> When it's being initially installed it won't have the additional command line
> flag that forces it to ignore the EFI check, so it won't run and you would
> have to run it manually afterwards with the flag. I agree that an env
> variable/config file would be better here.
> 
> > The name FK_FORCE_EFI=yes seems a bit backwards; it is ignoring 
> 
> the presence of EFI, not forcing it to behave like EFI. FK_FORCE_NO_EFI?
> FK_IGNORE_EFI? Names are hard.
> 
> My intention behind the name was something like "force *despite* EFI", but I
> think FK_IGNORE_EFI does indeed fit a lot better. .
> 
> > I overall like this approach, although the main drawback is having to write
> > to /etc/default/flash-kernel 
> 
> I agree with this - it's a bit more awkward having to create and write a
> file, but I like that it opens the door to allow both methods to work. The
> user can either set the env variable, or it can be set in the file itself.

I've had a private chat with Vagrant yesterday and we agreed that the best way
forward would be to solve this in the same way the environment variable
FK_MACHINE works which can also be set using /etc/flash-kernel/machine and is
essentially and override for /proc/device-tree/model.

So in the same fashion we could have FK_IGNORE_EFI as an environment variable
which can also be set by having /etc/flash-kernel/ignore-efi which is an
override for the existence of /sys/firmware/efi.

Would you like to amend your patch to add support for
/etc/flash-kernel/ignore-efi in addition to FK_IGNORE_EFI? I'd be willing to
test the result in our CI environment. :)

> I'm not sure if it makes sense to add the "! ischroot" check like in that
> merge request though, as I feel like that's a different topic. What do you
> think?

The "! ischroot" is not strictly required for my use-case. I added it because
with it, we get the nice property, that outside of a chroot (i.e. when not
creating a bootable image for another machine) the presence of efi will not get
ignored. This would mean that after creating the bootable image, one would not
have to remove /etc/flash-kernel/ignore-efi to get back to a system that
potentially could support efi in the future. But I do not require this extra
complexity. I think there is value in making FK_IGNORE_EFI behave the same as
FK_MACHINE without any hidden surprises like the "! ischroot" check.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Cyril Brulebois]

Hi,

Sorry it took some time to reply to that particular bug…

Pascal Hambourg  (2023-04-17):
> On 07/04/2023 at 01:05, I wrote:
> > Ugly attached patch works for me as PoC.
> > Copy fd 0 into fd 9 (because it looked unused) before entering the
> > pipeline, and restore it when running install_firmware_pkg.

I think I'd be happy to take this patch for bookworm, as a workaround…

> Here is another patch for hw-detect moving the install_firmware_pkg()
> call outside the pipeline instead of playing with file descriptors.

… before considering a real/better fix after bookworm.

> PS: shouldn't this bug report be reassigned to hw-detect ?

Where the bug comes from seems pretty clear by now, so feel free to
reassign, and maybe clone it so that we can track the workaround
(bookworm) and the fix (post-bookworm).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Processed: Re: Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Debian Bug Tracking System]

Processing control commands:

> tags -1 patch
Bug #1033921 [debian-installer] debian-installer: Weekly build of d-i fails to 
find ipw2x00 firmware package
Added tag(s) patch.

-- 
1033921: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033921
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Pascal Hambourg]

Control: tags -1 patch

On 07/04/2023 at 01:05, I wrote:


Ugly attached patch works for me as PoC.
Copy fd 0 into fd 9 (because it looked unused) before entering the 
pipeline, and restore it when running install_firmware_pkg.


Here is another patch for hw-detect moving the install_firmware_pkg() 
call outside the pipeline instead of playing with file descriptors.


PS: shouldn't this bug report be reassigned to hw-detect ?From 5186662ea53ff694ba3fc841f623a521c9091d54 Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Mon, 17 Apr 2023 15:16:20 +0200
Subject: [PATCH] check-missing-firmware: Fix firmware license acceptance

The standard input of a command run within a pipeline is redirected,
which disrupts debconf. So move the install_firmware_pkg() call out
of the pipeline, else the debconf dialog is not displayed when the
firmware package preinst script requires a license acceptance.
---
 check-missing-firmware.sh | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh
index 5db0e180..5ea194d7 100755
--- a/check-missing-firmware.sh
+++ b/check-missing-firmware.sh
@@ -318,18 +318,32 @@ install_firmware_pkg () {
 # This does not use anna because debs can have arbitrary
 # dependencies, which anna might try to install.
 check_for_firmware() {
+	# any non-space character which is not a shell pattern meta-character * ? ! [ ]
+	# and cannot be part of a component name a-z - will do as a delimiter
+	local delim="^"
+	local list item dir fw_file fw_pkg_file component filename
+
 	echo "$files" | sed -e 's/ /\n/g' >/tmp/grepfor
 	for dir in $@; do
 		# An index file might exist, mapping firmware files to firmware
 		# packages, saving us from iterating over each firmware *.deb:
 		if [ -f $dir/Contents-firmware ]; then
 			log "lookup with $dir/Contents-firmware"
+			# environment modification in a pipeline is not persistent, so use stdout
+			list=$(\
 			grep -f /tmp/grepfor $dir/Contents-firmware | while read fw_file fw_pkg_file component; do
+echo $fw_pkg_file$delim$component
+			done)
+			# do not call install_firmware_pkg() inside a pipeline because stdin is redirected,
+			# it disrupts debconf in the package preinst script if license agreement is required
+			for item in $(echo $list); do
+fw_pkg_file=${item%$delim*}
 # Don't install a package for each file it ships!
 if grep -qs "^$fw_pkg_file$" /tmp/pkginstalled 2>/dev/null; then
 	continue
 fi
 if check_deb_arch "$dir/$fw_pkg_file"; then
+	component=${item##*$delim}
 	log "installing firmware package $dir/$fw_pkg_file ($component)"
 	install_firmware_pkg "$dir/$fw_pkg_file" "$component" || true
 	echo "$fw_pkg_file" >> /tmp/pkginstalled
-- 
2.30.2

Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

[Isaac True]

> Why would you have to run flash-kernel again?

When it's being initially installed it won't have the additional command line 
flag that forces it to ignore the EFI check, so it won't run and you would have 
to run it manually afterwards with the flag. I agree that an env 
variable/config file would be better here.

> The name FK_FORCE_EFI=yes seems a bit backwards; it is ignoring 
the presence of EFI, not forcing it to behave like EFI. FK_FORCE_NO_EFI? 
FK_IGNORE_EFI? Names are hard.

My intention behind the name was something like "force *despite* EFI", but I 
think FK_IGNORE_EFI does indeed fit a lot better.  

> I overall like this approach, although the main drawback is having to write 
> to /etc/default/flash-kernel 

I agree with this - it's a bit more awkward having to create and write a file, 
but I like that it opens the door to allow both methods to work. The user can 
either set the env variable, or it can be set in the file itself. I'm not sure 
if it makes sense to add the "! ischroot" check like in that merge request 
though, as I feel like that's a different topic. What do you think?

Cheers,
Isaac