Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #76695 > unrolled thread

Bug#1022848: linux: 6.0.5 fixes critical btrfs bug

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1022848: linux: 6.0.5 fixes critical btrfs bug Christoph Anton Mitterer <calestyo@scientia.org> - 2022-10-26 22:30 +0200
    Bug#1022848: linux: 6.0.5 fixes critical btrfs bug Christoph Anton Mitterer <calestyo@gmail.com> - 2022-10-26 22:50 +0200
    Processed: Re: Bug#1022848: linux: 6.0.5 fixes critical btrfs bug "Debian Bug Tracking System" <owner@bugs.debian.org> - 2022-10-27 21:10 +0200
    Bug#1022848: linux: 6.0.5 fixes critical btrfs bug Salvatore Bonaccorso <carnil@debian.org> - 2022-10-27 21:10 +0200
      Bug#1022848: linux: 6.0.5 fixes critical btrfs bug Christoph Anton Mitterer <calestyo@scientia.org> - 2022-10-27 21:30 +0200
        Bug#1022848: linux: 6.0.5 fixes critical btrfs bug Salvatore Bonaccorso <carnil@debian.org> - 2022-10-28 07:00 +0200
          Bug#1022848: linux: 6.0.5 fixes critical btrfs bug Christoph Anton Mitterer <calestyo@scientia.org> - 2022-10-29 00:40 +0200
            Bug#1022848: linux: 6.0.5 fixes critical btrfs bug Salvatore Bonaccorso <carnil@debian.org> - 2022-10-29 09:40 +0200
    Processed: Re: Bug#1022848: linux: 6.0.5 fixes critical btrfs bug "Debian Bug Tracking System" <owner@bugs.debian.org> - 2022-10-28 07:00 +0200

#76695 — 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.camel@scientia.org/T/#u
https://lore.kernel.org/linux-btrfs/1c531dd5de7477c8b6ec15d4aebb8e42ae460925.camel@scientia.org/T/#t
https://lore.kernel.org/linux-btrfs/Y1krzbq3zdYOSQYG@bulldog/T/#u
https://lore.kernel.org/all/10522366-5c17-c18f-523c-b97c1496927b@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&id=217fd7557896d990c3dd8beea83a6feeb504f235


Thanks,
Chris.

[toc] | [next] | [standalone]

#76696

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

[toc] | [prev] | [next] | [standalone]

#76720 — 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 owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#76721

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

[toc] | [prev] | [next] | [standalone]

#76723

Am 27. Oktober 2022 20:56:49 MESZ schrieb Salvatore Bonaccorso <carnil@debian.org>:
>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. 

[toc] | [prev] | [next] | [standalone]

#76731

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 <carnil@debian.org>:
> >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

[toc] | [prev] | [next] | [standalone]

#76780

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.

[toc] | [prev] | [next] | [standalone]

#76803

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

[toc] | [prev] | [next] | [standalone]

#76730 — 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 owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web