Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
On Sat, 2022-10-29 at 09:23 +0200, Salvatore Bonaccorso wrote: > > No unfortunately we cannot do that. The reason is similar to what > lead > to > https://salsa.debian.org/kernel-team/linux/-/commit/248736d493fcfd0e05cd23f97befe40f5c125c71 > or caused bugs like #916927. Forgive me my ignorance, but from the package's file list I'd assume that the signatures are included in the kernel image respectively the module files themselves? Is that a must, or could they be standalone signatures? Cause if the latter, wouldn't something like the following be possible: - have only one package that actually contains the kernel and modules (and that would be available earlier) - have that depend on a separate package that ships the standalone signatures That would have the benefit that there are no "duplicate" packages, and people could create a dummy for the signature package with e.g. equivs. > The signed packages need always longer as this needs action of > signing > them trough a seprate manual process of ftp-masters. Sure, clear. Best wishes, Chris.
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
On 2022-10-29 09:23, Salvatore Bonaccorso wrote: So question is,.. would it make sense to request that linux-image-amd64 depends on the signed | unsigned version? No unfortunately we cannot do that. The reason is similar to what lead to https://salsa.debian.org/kernel-team/linux/-/commit/248736d493fcfd0e05cd23f97befe40f5c125c71 or caused bugs like #916927. In meanwhile furthermore linux-image-amd64 is anyway not anymore from a separate metapackage but built from linux-signed-amd64. The signed packages need always longer as this needs action of signing them trough a seprate manual process of ftp-masters. What about linux-image-amd64-unsigned?
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Hi Christoph, On Sat, Oct 29, 2022 at 12:36:01AM +0200, Christoph Anton Mitterer wrote: > Hey Salvatore. > > On Fri, 2022-10-28 at 06:49 +0200, Salvatore Bonaccorso wrote: > > I did decide to still do so, so we can have the CVE fix migrate > > finally to testing (which took some time as well given there was the > > perl transition ongoing). > > Fine for me... I think it would be nice if there was a better mechanism > to have bugs shown in apt-listbugs out of the box, while still not > preventing migration to testing. There is one, involving the release team that they can force a specific version. In fact I was offlist in contact with Sebastian Ramacher from the release team who could have done so. In the end the src:linux was able to migrate on the next run, so downgrading the bug severity was the quickest action without need to let a release team emmber intervene. In the end, yes, the cleanest solution, assuming kernel-team considered the bug a RC bug, it would have been the right solution to just ask the release team to force the migration despite of the RC bug. > Oh and another off-topic thing: > > Right now the kernel image meta-packages depend on the (secure boot) > signed version of that... and it seems that these take always longer to > be available than the unsigned ones. > > However, if people want the nice service to have linux-image-amd64 > installed and pull in just the current package, they need to wait for > the signed one to become available - even if they don't use secure boot > at all. > > So question is,.. would it make sense to request that linux-image-amd64 > depends on the signed | unsigned version? No unfortunately we cannot do that. The reason is similar to what lead to https://salsa.debian.org/kernel-team/linux/-/commit/248736d493fcfd0e05cd23f97befe40f5c125c71 or caused bugs like #916927. In meanwhile furthermore linux-image-amd64 is anyway not anymore from a separate metapackage but built from linux-signed-amd64. The signed packages need always longer as this needs action of signing them trough a seprate manual process of ftp-masters. > > I did import already 6.0.5 and will upload next so we get the btrfs > > fix. And I have made the bug now as well again back RC severity. > > Thanks as always for your continued efforts. Thank you for those encouraging words! Salvatore
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Hey Salvatore. On Fri, 2022-10-28 at 06:49 +0200, Salvatore Bonaccorso wrote: > I did decide to still do so, so we can have the CVE fix migrate > finally to testing (which took some time as well given there was the > perl transition ongoing). Fine for me... I think it would be nice if there was a better mechanism to have bugs shown in apt-listbugs out of the box, while still not preventing migration to testing. Oh and another off-topic thing: Right now the kernel image meta-packages depend on the (secure boot) signed version of that... and it seems that these take always longer to be available than the unsigned ones. However, if people want the nice service to have linux-image-amd64 installed and pull in just the current package, they need to wait for the signed one to become available - even if they don't use secure boot at all. So question is,.. would it make sense to request that linux-image-amd64 depends on the signed | unsigned version? > I did import already 6.0.5 and will upload next so we get the btrfs > fix. And I have made the bug now as well again back RC severity. Thanks as always for your continued efforts. Cheers, Chris.
Processed: Re: Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Processing control commands: > severity -1 serious Bug #1022848 [src:linux] 6.0.5 fixes critical btrfs bug in 6.0.3, affecting space cache v1 filesystems Severity set to 'serious' from 'important' -- 1022848: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022848 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Control: severity -1 serious Hi Christoph, Thanks for the quick feedback! On Thu, Oct 27, 2022 at 09:10:53PM +0200, Christoph Anton Mitterer wrote: > Am 27. Oktober 2022 20:56:49 MESZ schrieb Salvatore Bonaccorso > : > >According to your references there is the workaround of mounting with > >clear_cache,space_cache=v2 and convert the filesystem. > > > >What would one prevent doing so? > > v2 space cache is still rather new and had only recently some bug > that could have caused catastrophic data corruption... so not > everyone might want to switch. > > Similarly, people may want to have these filesystems mounted with > older kernels, whose v2 support isn't that good yet. Thanks, this is very important input. > >I'm downgrading the severity to important as it does not make the > >kernel unbootable or unstable on common hardware or all systems that a > >flavour is supposed to support. > > But now it a) migrates to testing an possibly leaves even more > systems with an unbootable system... b) with severity important, > people using e.g. apr-listbugs won't see it. > > OTOH, fixing the CVE is of course important, too. I did decide to still do so, so we can have the CVE fix migrate finally to testing (which took some time as well given there was the perl transition ongoing). I did import already 6.0.5 and will upload next so we get the btrfs fix. And I have made the bug now as well again back RC severity. Thank you! Regards, Salvatore
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Am 27. Oktober 2022 20:56:49 MESZ schrieb Salvatore Bonaccorso : >According to your references there is the workaround of mounting with >clear_cache,space_cache=v2 and convert the filesystem. > >What would one prevent doing so? v2 space cache is still rather new and had only recently some bug that could have caused catastrophic data corruption... so not everyone might want to switch. Similarly, people may want to have these filesystems mounted with older kernels, whose v2 support isn't that good yet. >I'm downgrading the severity to important as it does not make the >kernel unbootable or unstable on common hardware or all systems that a >flavour is supposed to support. But now it a) migrates to testing an possibly leaves even more systems with an unbootable system... b) with severity important, people using e.g. apr-listbugs won't see it. OTOH, fixing the CVE is of course important, too. Cheers, Chris.
Processed: Re: Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Processing control commands: > severity -1 important Bug #1022848 [src:linux] 6.0.5 fixes critical btrfs bug in 6.0.3, affecting space cache v1 filesystems Severity set to 'important' from 'critical' -- 1022848: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022848 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Control: severity -1 important Hi, On Wed, Oct 26, 2022 at 10:23:35PM +0200, Christoph Anton Mitterer wrote: > Source: linux > Version: 5.19.6-1 > Severity: critical > Justification: breaks the whole system > > > Hi. > > 6.0.3 introduced a commit that causes (permanent) CPU soft lockups > for some people with btrfs filesystems, effectively breaking the > system, e.g. when booting. According to your references there is the workaround of mounting with clear_cache,space_cache=v2 and convert the filesystem. What would one prevent doing so? I'm downgrading the severity to important as it does not make the kernel unbootable or unstable on common hardware or all systems that a flavour is supposed to support. While I agree it is important to fix, this issue should not block the migration of the current kernel to address CVE-2022-2602. I will work next on importing the newer 6.0.y versions which include a fix for this issue as well. Regards, Salvatore
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Control: retitle -1 6.0.5 fixes critical btrfs bug in 6.0.3, affecting space cache v1 filesystems Control: notfound -1 5.19.6-1 Control: found -1 6.0.3-1 No idea why reportbug picked 5.19.6, which I have not even installed anymore... o.O
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
Source: linux Version: 5.19.6-1 Severity: critical Justification: breaks the whole system Hi. 6.0.3 introduced a commit that causes (permanent) CPU soft lockups for some people with btrfs filesystems, effectively breaking the system, e.g. when booting. See e.g. https://lore.kernel.org/linux-btrfs/2291416ef48d98059f9fdc5d865b0ff040148237.ca...@scientia.org/T/#u https://lore.kernel.org/linux-btrfs/1c531dd5de7477c8b6ec15d4aebb8e42ae460925.ca...@scientia.org/T/#t https://lore.kernel.org/linux-btrfs/Y1krzbq3zdYOSQYG@bulldog/T/#u https://lore.kernel.org/all/10522366-5c17-c18f-523c-b97c14969...@net4u.de/ https://bugs.archlinux.org/task/76266 6.0.5 is ought to fix that, could you please upgrade sid ASAP? :-) See: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.0.5=217fd7557896d990c3dd8beea83a6feeb504f235 Thanks, Chris.
