Bug#1035282: firmware-brcm80211: broken symlinks: /lib/firmware/brcm/brcmfmac4356-sdio.*,*.txt -> brcmfmac4356-sdio.AP6356S.txt

[Salvatore Bonaccorso]

Hi,

On Sun, Apr 30, 2023 at 03:18:08AM +0200, Andreas Beckmann wrote:
> Package: firmware-brcm80211
> Version: 20230210-4
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
> >From the attached log (scroll to the bottom...):
> 
> 0m14.9s ERROR: WARN: Broken symlinks:
>   /lib/firmware/brcm/brcmfmac4356-sdio.khadas,vim2.txt -> 
> brcmfmac4356-sdio.AP6356S.txt (firmware-brcm80211)
>   /lib/firmware/brcm/brcmfmac4356-sdio.vamrs,rock960.txt -> 
> brcmfmac4356-sdio.AP6356S.txt (firmware-brcm80211)
> 
> Severity serious, since this likely means that the kernel cannot find
> the firmware at the expected location.

Seems to be a consequence of upstream's change in 4ffcf980a535 ("brcm:
rename Rock960 NVRAM to AP6356S and link devices to it") in 20220411.

In the Debian packaging adding the nvram for 96boards Rock960,
happened in 20210208-1, so at least stable users indeed might suffer
from a problem switching from bullseye to bookworm. For the one with
khadas VIM2's WiFi,s there is no regreession at least as the symlink
was added in 20210511-1~exp1.

Will have a look.

Regards,
Salvatore

Processed: found 1035282 in 20220913-1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 1035282 20220913-1
Bug #1035282 [firmware-brcm80211] firmware-brcm80211: broken symlinks: 
/lib/firmware/brcm/brcmfmac4356-sdio.*,*.txt -> brcmfmac4356-sdio.AP6356S.txt
Marked as found in versions firmware-nonfree/20220913-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1035282: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035282
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#905745: util-linux: tty hijacking possible in "su" via TIOCSTI ioctl

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:util-linux
Bug #905745 [src:linux] util-linux: tty hijacking possible in "su" via TIOCSTI 
ioctl
Bug reassigned from package 'src:linux' to 'src:util-linux'.
Ignoring request to alter found versions of bug #905745 to the same values 
previously set
Ignoring request to alter fixed versions of bug #905745 to the same values 
previously set

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

Re: Bug#905745: util-linux: tty hijacking possible in "su" via TIOCSTI ioctl

[Salvatore Bonaccorso]

Control: reassign -1 src:util-linux

Hi Cris,

On Sat, Apr 29, 2023 at 11:47:40PM +0200, Chris Hofstaedtler wrote:
> Control: reassign -1 src:linux
> Control: affects -1 src:util-linux
> 
> Dear Kernel Maintainers, Security Team,
> 
> * Sam Morris :
> > Linux 6.2 introduces a sysctl dev.tty.legacy_tiocsti sysctl which can be
> > used to disable TIOCSTI. The default value of the sysctl is set at build
> > time with CONFIG_LEGACY_TIOCSTI.
> > 
> > 
> 
> Maybe we can get this into 6.1?

(For the metainformation I'm assigning it back to su, where the CVE(s)
originally got assigned, but we can close the bug in future once the
root issue is addressed on kernel side, I hope you are okay with
that).

It is unlikely we are going to enable this in bookworm, even if the
change will be backported to 6.1.y, that is if the change would now be
backported, I assume we will need to stick with the default being
enabled. The time was too narrow before the
freeze. But we have #1033095[1] for the corresponding bug on src:linux
and to disable TIOCSTI it early in the trixie development cycle by
default (which comes automatically).

 [1]: https://bugs.debian.org/1033095

Hope this helps so far?

Regards,
Salvatore

Bug#1035282: firmware-brcm80211: broken symlinks: /lib/firmware/brcm/brcmfmac4356-sdio.*,*.txt -> brcmfmac4356-sdio.AP6356S.txt

[Andreas Beckmann]

Package: firmware-brcm80211
Version: 20230210-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m14.9s ERROR: WARN: Broken symlinks:
  /lib/firmware/brcm/brcmfmac4356-sdio.khadas,vim2.txt -> 
brcmfmac4356-sdio.AP6356S.txt (firmware-brcm80211)
  /lib/firmware/brcm/brcmfmac4356-sdio.vamrs,rock960.txt -> 
brcmfmac4356-sdio.AP6356S.txt (firmware-brcm80211)

Severity serious, since this likely means that the kernel cannot find
the firmware at the expected location.


cheers,

Andreas


firmware-brcm80211_20230210-4.log.gz
Description: application/gzip

Bug#1035281: firmware-intel-sound: broken symlinks: /lib/firmware/intel/dsp_fw_*.bin -> avs/*/dsp_basefw.bin

[Andreas Beckmann]

Package: firmware-intel-sound
Version: 20230310-1~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
broken symlinks.

>From the attached log (scroll to the bottom...):

0m13.1s ERROR: WARN: Broken symlinks:
  /lib/firmware/intel/dsp_fw_bxtn.bin -> avs/apl/dsp_basefw.bin 
(firmware-intel-sound)
  /lib/firmware/intel/dsp_fw_cnl.bin -> avs/cnl/dsp_basefw.bin 
(firmware-intel-sound)
  /lib/firmware/intel/dsp_fw_glk.bin -> avs/apl/dsp_basefw.bin 
(firmware-intel-sound)
  /lib/firmware/intel/dsp_fw_kbl.bin -> avs/skl/dsp_basefw.bin 
(firmware-intel-sound)
  /lib/firmware/intel/dsp_fw_release.bin -> avs/skl/dsp_basefw.bin 
(firmware-intel-sound)

Severity serious, since that likely means the firmware is missing at
the expected location.

cheers,

Andreas


firmware-intel-sound_20230310-1~exp1.log.gz
Description: application/gzip

Bug#1035118: linux-base: Presence of GPG signatures in /boot causes wrong kernels to be listed with linux-version

[abrasamji]

Package: linux-base
Version: 4.6
Severity: important
X-Debbugs-Cc: debian.62...@simplelogin.com

Dear Maintainer,

Grub2 supports additional secure boot capabilities that are not commonly used 
but are required for security. These new features are being referenced in some 
security guides online.  An end user may sign their initrd.img and vmlinuz 
files with a GPG detached signature. See Grub2's manual, section 18.2 "Using 
digital signatures in GRUB" for details.

Presence of these detached signatures causes the "linux-version" script to 
return the .sig files as valid kernels.  Thus, when something runs 
update-initramfs -u (which calls "linux-version list"), the initramfs script 
will ingest the output from linux-version and overwrite an initrd.sig file with 
an initramfs, as well as several other negative effects from not having the 
proper kernel modules available.

The impact is an unbootable system, where Grub attempts to boot the correct 
kernel, but the initrd.img is not updated with new data, and the signature for 
the original initrd.img is overwritten with improper data. System can be 
recovered by picking an old kernel in the grub bootloader.

Thank you

-- System Information:
Debian Release: 11.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'bullseye-fasttrack')
Architecture: amd64 (x86_64)

Kernel: Linux 6.2.13-stripes-1-s-1.58 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_RANDSTRUCT
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-base depends on:
ii  debconf [debconf-2.0]  1.5.77

linux-base recommends no packages.

linux-base suggests no packages.

-- debconf information:
  linux-base/removing-title:
  linux-base/removing-running-kernel: true

Re: Bug#905745: util-linux: tty hijacking possible in "su" via TIOCSTI ioctl

[Chris Hofstaedtler]

Control: reassign -1 src:linux
Control: affects -1 src:util-linux

Dear Kernel Maintainers, Security Team,

* Sam Morris :
> Linux 6.2 introduces a sysctl dev.tty.legacy_tiocsti sysctl which can be
> used to disable TIOCSTI. The default value of the sysctl is set at build
> time with CONFIG_LEGACY_TIOCSTI.
> 
> 

Maybe we can get this into 6.1?

Thanks,
Chris

Processed: Re: Bug#905745: util-linux: tty hijacking possible in "su" via TIOCSTI ioctl

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:linux
Bug #905745 [util-linux] util-linux: tty hijacking possible in "su" via TIOCSTI 
ioctl
Bug reassigned from package 'util-linux' to 'src:linux'.
No longer marked as found in versions util-linux/2.32-0.4.
Ignoring request to alter fixed versions of bug #905745 to the same values 
previously set
> affects -1 src:util-linux
Bug #905745 [src:linux] util-linux: tty hijacking possible in "su" via TIOCSTI 
ioctl
Added indication that 905745 affects src:util-linux

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

Re: Bug#1035101: Failed to detect HD if Intel RST-RAID is active

[Thomas Viehweger]

Apparently we have that option enabled in the regular linux package:

 debian/config/kernelarch-x86/config:CONFIG_INTEL_RST=m

but the relevant module isn't shipped in any udebs:

 /lib/modules//kernel/drivers/platform/x86/intel/intel-rst.ko

Would you be willing to test an unofficial amd64 netinst image that
would ship that extra module, to see if the installer (1) sees the disk
and (2) can do something with it?


Hi,

I am able to do one test...

Re: Bug#1035101: Failed to detect HD if Intel RST-RAID is active

[Cyril Brulebois]

Hallo Thomas,

and thanks for your report.

Thomas Viehweger  (2023-04-29):
> Detect hard drives: [E]
> 
> The Hard disk was not detected because Intel RST was configured in
> RAID mode.
> 
> Tried Ubuntu 23.04 installer which gives the correct hint.
> 
> After configuring Intel RST to AHCI mode, the harddisk was detected
> and installation was successful.
> 
> It would be nice if this installer could check the RST mode, too.

Apparently we have that option enabled in the regular linux package:

debian/config/kernelarch-x86/config:CONFIG_INTEL_RST=m

but the relevant module isn't shipped in any udebs:

/lib/modules//kernel/drivers/platform/x86/intel/intel-rst.ko

Would you be willing to test an unofficial amd64 netinst image that
would ship that extra module, to see if the installer (1) sees the disk
and (2) can do something with it?

(Also putting the kernel team in the loop.)


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


signature.asc
Description: PGP signature

Processed: reassign 1035097 to grub2-common, reassign 1031826 to src:linux

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 1035097 grub2-common
Bug #1035097 [grub-install] grub-install: efivars_set_variable fails due to 
dump-* files in /sys/firmware/efi/efivars
Warning: Unknown package 'grub-install'
Bug reassigned from package 'grub-install' to 'grub2-common'.
Ignoring request to alter found versions of bug #1035097 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1035097 to the same values 
previously set
> reassign 1031826 src:linux 5.10.162-1
Bug #1031826 [linux-image-5.10.0-21-amd64] tty clock speed not being set 
properly in debian kernel on iBase hardware
Warning: Unknown package 'linux-image-5.10.0-21-amd64'
Bug reassigned from package 'linux-image-5.10.0-21-amd64' to 'src:linux'.
Ignoring request to alter found versions of bug #1031826 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1031826 to the same values 
previously set
Bug #1031826 [src:linux] tty clock speed not being set properly in debian 
kernel on iBase hardware
Marked as found in versions linux/5.10.162-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1031826: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031826
1035097: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035097
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

[Salvatore Bonaccorso]

Hi Aurelien,

On Sat, Apr 29, 2023 at 09:50:57AM +0200, Aurelien Jarno wrote:
> control: reassign -1 pahole/1.24-4
> control: retitle -1 pahole: BTF deduplication issues causing arm64 kernel 
> size increase
> control: tag -1 + fixed-upstream
> control: tag -1 + patch
> control: affects -1 u-boot-rpi src:linux
> 
> Hi,
> 
> On 2023-03-21 23:11, Aurelien Jarno wrote:
> > Source: linux
> > Version: 6.1.15-1
> > Severity: important
> > Tags: upstream
> > X-Debbugs-Cc: vagr...@debian.org
> > Control: affects -1 + u-boot-rpi
> > 
> > Hi,
> > 
> > Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
> > Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
> > to boot with:
> > 
> > | 40175552 bytes read in 1695 ms (23 MiB/s)
> > | 43794863 bytes read in 1817 ms (23 MiB/s)
> > | Moving Image from 0x8 to 0x20, end=299
> > | ERROR: RD image overlaps OS image (OS=0x20..0x299)
> > 
> > I tracked the issue to a significant increase of the kernel size between
> > version 6.1.12-1 and 6.15-1:
> > 
> > | 31492   /boot/vmlinuz-6.1.0-5-arm64
> > | 39236   /boot/vmlinuz-6.1.0-6-arm64
> > 
> > This is more than the 36MB that is allowed by u-boot with the default
> > load addresses. A workaround is to shift the load addresses at the
> > u-boot level as in the attached patch.
> > 
> > I have tracked issue on the upstream kernel side to the following commit
> > on the stable tree:
> > 
> > | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
> > | Author: Masahiro Yamada 
> > | Date:   Thu Oct 13 08:35:00 2022 +0900
> > | 
> > | arm64: remove special treatment for the link order of head.o
> > | 
> > | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
> > | 
> > | In the previous discussion (see the Link tag), Ard pointed out that
> > | arm/arm64/kernel/head.o does not need any special treatment - the only
> > | piece that must appear right at the start of the binary image is the
> > | image header which is emitted into .head.text.
> > | 
> > | The linker script does the right thing to do. The build system does
> > | not need to manipulate the link order of head.o.
> > | 
> > | Link: 
> > https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
> > | Suggested-by: Ard Biesheuvel 
> > | Signed-off-by: Masahiro Yamada 
> > | Reviewed-by: Nicolas Schier 
> > | Link: 
> > https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
> > | Signed-off-by: Will Deacon 
> > | Signed-off-by: Tom Saeger 
> > | Signed-off-by: Greg Kroah-Hartman 
> > 
> > The problem is still reproducible on Linus' master.
> > 
> > I am reporting the bug to the linux package as I believed there is no
> > real reason for such an increase in the kernel size. In case I missed
> > something and this is actually wanted, the bug can be reassigned to the
> > u-boot package.
> 
> This has been discussed upstream, and it appears that the issue is not
> reproducible with pahole 1.25. Looking at the part that needs to be
> backported to the Debian package, I have found that the issue is caused
> by the following patch backported in version 1.24-4:
> 
> 02-encode-DW_TAG_unspecified_type-returning-routines-as-void.patch
> 
> This patch has an issue, and memory is not initialized after allocation,
> so garbage values are used instead. A one-liner fix has been committed
> upstream not so long after the initial patch:
> 
> https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=b72f5188856df0abf45e1a707856bb4e4e86153c
> 
> I am therefore reassigning the bug to pahole where the bug should be
> fixed. Even if Bookworm is now fully frozen, I personally believe this
> bug should still be fixed before the release. That said, this has to be
> discussed with the release team, and as pahole is a key package you need
> a pre-approval *before* the upload to sid. 

Thanks for tracking this down!

Domenico, I would say, it would eben be good to have this in in the
archive for bookworm before the next (last?) linux upload for bookworm
ideally. This is not yet planned but, the last one should probably be
latest in the week of 15th May.

Regards,
Salvatore

Processed: reassign 1033301 to pahole

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 1033301 pahole 1.24-4
Bug #1033301 [src:linux] pahole: BTF deduplication issues causing arm64 kernel 
size increase
Bug reassigned from package 'src:linux' to 'pahole'.
No longer marked as found in versions linux/6.1.15-1.
Ignoring request to alter fixed versions of bug #1033301 to the same values 
previously set
Bug #1033301 [pahole] pahole: BTF deduplication issues causing arm64 kernel 
size increase
Marked as found in versions dwarves/1.24-4.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1033301: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033301
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed (with 1 error): Re: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 pahole/1.24-4
Unknown command or malformed arguments to command.

> retitle -1 pahole: BTF deduplication issues causing arm64 kernel size increase
Bug #1033301 [src:linux] linux: arm64 kernel size increased from 31 to 39 MB, 
causing u-boot-rpi to fail
Changed Bug title to 'pahole: BTF deduplication issues causing arm64 kernel 
size increase' from 'linux: arm64 kernel size increased from 31 to 39 MB, 
causing u-boot-rpi to fail'.
> tag -1 + fixed-upstream
Bug #1033301 [src:linux] pahole: BTF deduplication issues causing arm64 kernel 
size increase
Added tag(s) fixed-upstream.
> tag -1 + patch
Bug #1033301 [src:linux] pahole: BTF deduplication issues causing arm64 kernel 
size increase
Added tag(s) patch.
> affects -1 u-boot-rpi src:linux
Bug #1033301 [src:linux] pahole: BTF deduplication issues causing arm64 kernel 
size increase
Added indication that 1033301 affects src:linux

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

Re: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

[Aurelien Jarno]

control: reassign -1 pahole/1.24-4
control: retitle -1 pahole: BTF deduplication issues causing arm64 kernel size 
increase
control: tag -1 + fixed-upstream
control: tag -1 + patch
control: affects -1 u-boot-rpi src:linux

Hi,

On 2023-03-21 23:11, Aurelien Jarno wrote:
> Source: linux
> Version: 6.1.15-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: vagr...@debian.org
> Control: affects -1 + u-boot-rpi
> 
> Hi,
> 
> Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
> Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
> to boot with:
> 
> | 40175552 bytes read in 1695 ms (23 MiB/s)
> | 43794863 bytes read in 1817 ms (23 MiB/s)
> | Moving Image from 0x8 to 0x20, end=299
> | ERROR: RD image overlaps OS image (OS=0x20..0x299)
> 
> I tracked the issue to a significant increase of the kernel size between
> version 6.1.12-1 and 6.15-1:
> 
> | 31492   /boot/vmlinuz-6.1.0-5-arm64
> | 39236   /boot/vmlinuz-6.1.0-6-arm64
> 
> This is more than the 36MB that is allowed by u-boot with the default
> load addresses. A workaround is to shift the load addresses at the
> u-boot level as in the attached patch.
> 
> I have tracked issue on the upstream kernel side to the following commit
> on the stable tree:
> 
> | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
> | Author: Masahiro Yamada 
> | Date:   Thu Oct 13 08:35:00 2022 +0900
> | 
> | arm64: remove special treatment for the link order of head.o
> | 
> | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
> | 
> | In the previous discussion (see the Link tag), Ard pointed out that
> | arm/arm64/kernel/head.o does not need any special treatment - the only
> | piece that must appear right at the start of the binary image is the
> | image header which is emitted into .head.text.
> | 
> | The linker script does the right thing to do. The build system does
> | not need to manipulate the link order of head.o.
> | 
> | Link: 
> https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
> | Suggested-by: Ard Biesheuvel 
> | Signed-off-by: Masahiro Yamada 
> | Reviewed-by: Nicolas Schier 
> | Link: 
> https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
> | Signed-off-by: Will Deacon 
> | Signed-off-by: Tom Saeger 
> | Signed-off-by: Greg Kroah-Hartman 
> 
> The problem is still reproducible on Linus' master.
> 
> I am reporting the bug to the linux package as I believed there is no
> real reason for such an increase in the kernel size. In case I missed
> something and this is actually wanted, the bug can be reassigned to the
> u-boot package.

This has been discussed upstream, and it appears that the issue is not
reproducible with pahole 1.25. Looking at the part that needs to be
backported to the Debian package, I have found that the issue is caused
by the following patch backported in version 1.24-4:

02-encode-DW_TAG_unspecified_type-returning-routines-as-void.patch

This patch has an issue, and memory is not initialized after allocation,
so garbage values are used instead. A one-liner fix has been committed
upstream not so long after the initial patch:

https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=b72f5188856df0abf45e1a707856bb4e4e86153c

I am therefore reassigning the bug to pahole where the bug should be
fixed. Even if Bookworm is now fully frozen, I personally believe this
bug should still be fixed before the release. That said, this has to be
discussed with the release team, and as pahole is a key package you need
a pre-approval *before* the upload to sid. 

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net