Bug 1223731 (CVE-2024-26944) - VUL-0: CVE-2024-26944: kernel: btrfs: zoned: use-after-free in do_zone_finish()
Summary: VUL-0: CVE-2024-26944: kernel: btrfs: zoned: use-after-free in do_zone_finish()
Status: NEW
Alias: CVE-2024-26944
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P2 - High : Major
Target Milestone: ---
Assignee: Filipe Manana
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/403713/
Whiteboard: CVSSv3.1:SUSE:CVE-2024-26944:7.8:(AV:...
Keywords:
Depends on:
Blocks:
 
Reported: 2024-05-02 12:12 UTC by SMASH SMASH
Modified: 2024-07-19 11:56 UTC (History)
5 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SMASH SMASH 2024-05-02 12:12:09 UTC
In the Linux kernel, the following vulnerability has been resolved:

btrfs: zoned: fix use-after-free in do_zone_finish()

Shinichiro reported the following use-after-free triggered by the device
replace operation in fstests btrfs/070.

 BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0
 ==================================================================
 BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs]
 Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007

 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G        W          6.8.0-rc5-kts #1
 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020
 Call Trace:
  <TASK>
  dump_stack_lvl+0x5b/0x90
  print_report+0xcf/0x670
  ? __virt_addr_valid+0x200/0x3e0
  kasan_report+0xd8/0x110
  ? do_zone_finish+0x91a/0xb90 [btrfs]
  ? do_zone_finish+0x91a/0xb90 [btrfs]
  do_zone_finish+0x91a/0xb90 [btrfs]
  btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs]
  ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs]
  ? btrfs_put_root+0x2d/0x220 [btrfs]
  ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs]
  cleaner_kthread+0x21e/0x380 [btrfs]
  ? __pfx_cleaner_kthread+0x10/0x10 [btrfs]
  kthread+0x2e3/0x3c0
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x31/0x70
  ? __pfx_kthread+0x10/0x10
  ret_from_fork_asm+0x1b/0x30
  </TASK>

 Allocated by task 3493983:
  kasan_save_stack+0x33/0x60
  kasan_save_track+0x14/0x30
  __kasan_kmalloc+0xaa/0xb0
  btrfs_alloc_device+0xb3/0x4e0 [btrfs]
  device_list_add.constprop.0+0x993/0x1630 [btrfs]
  btrfs_scan_one_device+0x219/0x3d0 [btrfs]
  btrfs_control_ioctl+0x26e/0x310 [btrfs]
  __x64_sys_ioctl+0x134/0x1b0
  do_syscall_64+0x99/0x190
  entry_SYSCALL_64_after_hwframe+0x6e/0x76

 Freed by task 3494056:
  kasan_save_stack+0x33/0x60
  kasan_save_track+0x14/0x30
  kasan_save_free_info+0x3f/0x60
  poison_slab_object+0x102/0x170
  __kasan_slab_free+0x32/0x70
  kfree+0x11b/0x320
  btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs]
  btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs]
  btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs]
  btrfs_ioctl+0xb27/0x57d0 [btrfs]
  __x64_sys_ioctl+0x134/0x1b0
  do_syscall_64+0x99/0x190
  entry_SYSCALL_64_after_hwframe+0x6e/0x76

 The buggy address belongs to the object at ffff8881543c8000
  which belongs to the cache kmalloc-1k of size 1024
 The buggy address is located 96 bytes inside of
  freed 1024-byte region [ffff8881543c8000, ffff8881543c8400)

 The buggy address belongs to the physical page:
 page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8
 head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
 flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
 page_type: 0xffffffff()
 raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002
 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 >ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                        ^
  ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

This UAF happens because we're accessing stale zone information of a
already removed btrfs_device in do_zone_finish().

The sequence of events is as follows:

btrfs_dev_replace_start
  btrfs_scrub_dev
   btrfs_dev_replace_finishing
    btrfs_dev_replace_update_device_in_mapping_tree <-- devices replaced
    btrfs_rm_dev_replace_free_srcdev
     btrfs_free_device                              <-- device freed

cleaner_kthread
 btrfs_delete_unused_bgs
  btrfs_zone_finish
   do_zone_finish              <-- refers the freed device

The reason for this is that we're using a
---truncated---

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-26944
https://www.cve.org/CVERecord?id=CVE-2024-26944
https://git.kernel.org/stable/c/1ec17ef59168a1a6f1105f5dc517f783839a5302
https://git.kernel.org/stable/c/34ca809e055eca5cfe63d9c7efbf80b7c21b4e57
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-26944.mbox
https://bugzilla.redhat.com/show_bug.cgi?id=2278210
Comment 3 Filipe Manana 2024-05-07 09:42:12 UTC
This is for zoned btrfs only. Do we actually support zoned filesystems on any SLE releases?
Comment 4 Goldwyn Rodrigues 2024-05-09 12:10:57 UTC
(In reply to Filipe Manana from comment #3)
> This is for zoned btrfs only. Do we actually support zoned filesystems on
> any SLE releases?

No we don't. We don't support zoned for TW either, though it may be enabled in the future. Fix is recommended but not mandatory.
Comment 7 Goldwyn Rodrigues 2024-07-09 02:29:41 UTC
I did a deeper check. The patch is relevant for v6.8 as indicated in the patch. The btrfs_block_group structure did not have physical_map variable, access to which shows up in the stack trace.

I am not sure if dev_replace.rwsem will be of any help.
Comment 8 Filipe Manana 2024-07-17 11:54:30 UTC
(In reply to Goldwyn Rodrigues from comment #7)
> I did a deeper check. The patch is relevant for v6.8 as indicated in the

Don't always guide by the version tagged in the CC stable line.
It's 6.8 because the backport is simple against 6.8 but complex and a lot of work for anything below it (see below why).

> patch. The btrfs_block_group structure did not have physical_map variable,

Are you sure? Which branch were you looking at?
It exists in both SLE15-SP6 and SLE15-SP5, just like in upstream kernels 6.4 and 5.18.

For SLE15-SP6:

https://github.com/SUSE/kernel/blob/SLE15-SP6/fs/btrfs/zoned.c#L1321

> access to which shows up in the stack trace.
> 
> I am not sure if dev_replace.rwsem will be of any help.

The use of the semaphore is precisely to have safe access to the ->physical_map member of a block group.

The problem with this patch is that it has a lot of dependencies.
In SLE kernels the physical_map is not reference counted, and I don't see a good way to solve it without making it reference counted, which happened in the following large patch from upstream (landed in kernel 6.8):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7dc66abb5a47778d7db327783a0ba172b8cff0b5

So adapting the fix to SLE15-SP6 without that change would result in code very different from what we have upstream, and make future backports diverging more and more.

Now that's an important change I would like to have in SLE15-SP6, since it would facilitate a lot of future backports.

But in order to do it, it needs the backport of several other fixes, cleanups and refactorings. I've been doing it and so far there's really a lot of patches, some of them quite large, so far 50 patches, which are:

commit b5345d6ceeee3ef378e4800f538c8fc06bf9de48            6.5-rc1
Author: Naohiro Aota <naota@elisp.net>
Date:   Wed Apr 26 00:19:40 2023 +0900

    btrfs: export bitmap_test_range_all_{set,zero}

commit f880fe6e0b4b127d6e2a007fe68bdf5651677ae2            6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon May 8 07:58:39 2023 -0700

    btrfs: don't hold an extra reference for redirtied buffers

commit adbe7e388e4239d9c1754d475aea791136927137           6.5-rc1
Author: Anand Jain <anand.jain@oracle.com>
Date:   Sat Apr 15 19:32:38 2023 +0800

    btrfs: use SECTOR_SHIFT to convert LBA to physical offset

commit dd8b7b0416704efb0dcd74801a1a48aa221f1cf5          6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:04 2023 +0200

    btrfs: optimize out btrfs_is_zoned for !CONFIG_BLK_DEV_ZONED

commit e9cb93b9fbd0bfcef2774e82d095362ad16acf6e         6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:05 2023 +0200

    btrfs: don't call btrfs_record_physical_zoned for failed append

commit 6e4b2479ab38b3f949a85964da212295d32102f0          6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:06 2023 +0200

    btrfs: mark the len field in struct btrfs_ordered_sum as unsigned

commit 5cfe76f846d5034058c0c4813259d5d831757c36             6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:07 2023 +0200

    btrfs: rename the bytenr field in struct btrfs_ordered_sum to logical

commit cbfce4c7fbde23cc8bcba44822a58c728caf6ec9           6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:08 2023 +0200

    btrfs: optimize the logical to physical mapping for zoned writes

commit 3887653c44ec1de089b8624bd53af05b946939e9           6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Jun 9 07:27:04 2023 +0200

    btrfs: record orig_physical only for the original bio

commit a6f3e205e4916e4f29ce2c4c38d520616e6b0080           6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:09 2023 +0200

    btrfs: move split_extent_map to extent_map.c

commit ebdb44a00e257641a398fe2484ba9c65a03beea1           6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:10 2023 +0200

    btrfs: reorder conditions in btrfs_extract_ordered_extent

commit b0307e28642efa3bcc6353b9af213711f6d3848e           6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:11 2023 +0200

    btrfs: return the new ordered_extent from btrfs_split_ordered_extent

commit 53d9981ca20efcded0f6cf6b480d713f490ca9f1           6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:13 2023 +0200

    btrfs: split btrfs_alloc_ordered_extent to allocation and insertion helpers

commit 816f589b8d43f7c258b0c10a5ce29daf01614651          6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:14 2023 +0200

    btrfs: atomically insert the new extent in btrfs_split_ordered_extent

commit 52b1fdca23ac0fbcad363a1a5b426bf0d56b715a          6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:15 2023 +0200

    btrfs: handle completed ordered extents in btrfs_split_ordered_extent

commit 71df088c1cc090d232eb691d8f42284a2c6409eb           6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:16 2023 +0200

    btrfs: defer splitting of ordered extents until I/O completion

commit 71df088c1cc090d232eb691d8f42284a2c6409eb           6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:16 2023 +0200

    btrfs: defer splitting of ordered extents until I/O completion

commit f000bc6fe43ce66c55fa1691000115b14ba95b33          6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 24 17:03:17 2023 +0200

    btrfs: pass the new logical address to split_extent_map

commit 3965a4c793d3b031119ff455c4773441584aee30          6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 31 06:17:34 2023 +0200

    btrfs: remove unused BTRFS_MAP_DISCARD

commit 78a213a05df3510200331bfcc232bf0278c6ed50         6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 31 06:17:35 2023 +0200

    btrfs: optimize simple reads in btrfsic_map_block
    
commit d69d7ffc26f10d7be3768a6762809c57f6443a43         6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 31 06:17:36 2023 +0200

    btrfs: remove unused btrfs_map_block

commit cd4efd210edfb34f8cec3a0184899af751dc2d71         6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 31 06:17:37 2023 +0200

    btrfs: rename __btrfs_map_block to btrfs_map_block

commit 723b8bb17e2e680934f59823ab1e72c1000d88d6         6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 31 06:17:38 2023 +0200

    btrfs: open code btrfs_map_sblock

commit 8680e58761eba8ea3552146ea005be30dfed2948         6.5-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed May 31 06:17:39 2023 +0200

    btrfs: open code need_full_stripe conditions

commit 07a3bb95ea1f7fa77e360cf3b0f06dff41dbf391         6.6-rc1
Author: Julia Lawall <Julia.Lawall@inria.fr>
Date:   Fri Jun 23 23:14:43 2023 +0200

    btrfs: zoned: use vcalloc instead of for vzalloc in btrfs_get_dev_zone_info

commit 861093eff4f01319edfc1d1ee276a7f2bf720f1d        6.6-rc1
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Aug 8 01:12:31 2023 +0900

    btrfs: introduce struct to consolidate extent buffer write context

commit 7db94301a980c9da4168ac7ce61e7bde297306ba         6.6-rc1
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Aug 8 01:12:32 2023 +0900

    btrfs: zoned: introduce block group context to btrfs_eb_write_context

commit 2ad8c0510a965113404cfe670b41ddc34fb66100         6.6-rc1
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Aug 8 01:12:33 2023 +0900

    btrfs: zoned: return int from btrfs_check_meta_write_pointer

commit 0356ad41e0ddb8cf0ea4d68820c92598413e445b         6.6-rc1
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Aug 8 01:12:34 2023 +0900

    btrfs: zoned: defer advancing meta write pointer

commit c1c3c2bc2917d09bbb19cb9894ba5950254b9502         6.6-rc1
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Aug 8 01:12:35 2023 +0900

    btrfs: zoned: update meta write pointer on zone finish

commit a7e1ac7bdc5af91af2d52e6269fdbd92fe9ee353         6.6-rc1
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Aug 8 01:12:36 2023 +0900

    btrfs: zoned: reserve zones for an active metadata/system block group

commit 13bb483d32abb6f8ebd40141d87eb68f11cc2dd2        6.6-rc1
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Aug 8 01:12:37 2023 +0900

    btrfs: zoned: activate metadata block group on write time

commit 6a8ebc773ef64c8f12d6d60fd6e53d5ccc81314b        6.6-rc1
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Aug 8 01:12:38 2023 +0900

    btrfs: zoned: no longer count fresh BG region as zone unusable

commit 5a7d107e5ef9b452cf0aa96ac931b29ea980d997        6.6-rc1
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Aug 8 01:12:39 2023 +0900

    btrfs: zoned: don't activate non-DATA BG on allocation

commit 5b135b382a360f4c87cf8896d1465b0b07f10cb0        6.6-rc1
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Aug 8 01:12:40 2023 +0900

    btrfs: zoned: re-enable metadata over-commit for zoned mode

commit 332581bde2a419d5f12a93a1cdc2856af649a3cc       6.6-rc1
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Fri Jul 21 16:42:14 2023 +0900

    btrfs: zoned: do not zone finish data relocation block group

commit c02d35d89b317994bd713ba82e160c5e7f22d9c8       6.6-rc1
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Sat Aug 19 01:26:07 2023 +0900

    btrfs: zoned: skip splitting and logical rewriting on pre-alloc write

commit ed3764f726b24099396734aa1a5b41ae7e0fac60      6.6-rc1
Author: Qu Wenruo <wqu@suse.com>
Date:   Tue Jun 27 15:34:31 2023 +0800

    btrfs: add comments for btrfs_map_block()

commit 9fb2acc2fe07f15b6cfe94a4bf910d3dfcd6e127       6.7-rc1
Author: Qu Wenruo <wqu@suse.com>
Date:   Sun Sep 17 19:36:21 2023 +0930

    btrfs: remove the need_raid_map parameter from btrfs_map_block()

commit 15c12fcc50a1b12a747f8b6ec05cdb18c537a4d1       6.7-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Jun 5 10:51:05 2023 +0200

    btrfs: zoned: introduce a zone_info struct in btrfs_load_block_group_zone_info

commit 09a46725cc84165af452d978a3532d6b97a28796       6.7-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Jun 5 10:51:06 2023 +0200

    btrfs: zoned: factor out per-zone logic from btrfs_load_block_group_zone_info

commit 9e0e3e74dc6928a0956f4e27e24d473c65887e96      6.7-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Jun 5 10:51:07 2023 +0200

    btrfs: zoned: factor out single bg handling from btrfs_load_block_group_zone_info

commit 87463f7e0250d471fac41e7c9c45ae21d83b5f85      6.7-rc1
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Jun 5 10:51:08 2023 +0200

    btrfs: zoned: factor out DUP bg handling from btrfs_load_block_group_zone_info

commit 7dc66abb5a47778d7db327783a0ba172b8cff0b5            6.8-rc1
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Nov 21 13:38:38 2023 +0000

    btrfs: use a dedicated data structure for chunk maps

commit 71fca47b644910485c49d1da31bc963cf286fe77           6.8-rc1
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Nov 21 13:38:39 2023 +0000

    btrfs: remove stripe size local variable from insert_dev_extents()

commit d967c914a633ee797255261808720f791b658f24          6.8-rc2
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Fri Dec 22 01:46:16 2023 +0900

    btrfs: fix unbalanced unlock of mapping_tree_lock

commit 88e81a67773017a2b93f6d5fe7c78bb0c5a6e4dd           6.8-rc5
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Feb 12 21:50:53 2024 +0000

    btrfs: zoned: fix chunk map leak when loading block group zone info

commit 1ec17ef59168a1a6f1105f5dc517f783839a5302            6.9-rc2
Author: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Date:   Wed Feb 28 12:13:27 2024 +0100

    btrfs: zoned: fix use-after-free in do_zone_finish()

commit cebae292e0c32a228e8f2219c270a7237be24a6a             6.10-rc5
Author: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Date:   Fri Jun 7 13:27:48 2024 +0200

    btrfs: zoned: allocate dummy checksums for zoned NODATASUM writes


And this is SLE15-SP6.

What do we do about SLE15-SP5?

And can we get it clear if we are going to support btrfs on zoned devices for SLE15-SP6, or SP5? There are more CVE fixes for zoned mode coming in, and they depend on previous fixes we don't have. There's also quite a lot of zoned fixes coming in frequently upstream, and that requires extra work which is very hard to find time for, considering the swarm of other CVEs and non-CVE fixes.

Goldwyn?
Comment 9 Goldwyn Rodrigues 2024-07-17 15:37:50 UTC
(In reply to Filipe Manana from comment #8)
> (In reply to Goldwyn Rodrigues from comment #7)
> > I did a deeper check. The patch is relevant for v6.8 as indicated in the
> 
> Don't always guide by the version tagged in the CC stable line.
> It's 6.8 because the backport is simple against 6.8 but complex and a lot of
> work for anything below it (see below why).
> 
> > patch. The btrfs_block_group structure did not have physical_map variable,
> 
> Are you sure? Which branch were you looking at?
> It exists in both SLE15-SP6 and SLE15-SP5, just like in upstream kernels 6.4
> and 5.18.

Looks like I tried SLE15-SP5 and it does not have the physical_map variable.

> 
> For SLE15-SP6:
> 
> https://github.com/SUSE/kernel/blob/SLE15-SP6/fs/btrfs/zoned.c#L1321
> 
> > access to which shows up in the stack trace.
> > 
> > I am not sure if dev_replace.rwsem will be of any help.
> 
> The use of the semaphore is precisely to have safe access to the
> ->physical_map member of a block group.
> 
> The problem with this patch is that it has a lot of dependencies.
> In SLE kernels the physical_map is not reference counted, and I don't see a
> good way to solve it without making it reference counted, which happened in
> the following large patch from upstream (landed in kernel 6.8):
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=7dc66abb5a47778d7db327783a0ba172b8cff0b5
> 
> So adapting the fix to SLE15-SP6 without that change would result in code
> very different from what we have upstream, and make future backports
> diverging more and more.
> 
> Now that's an important change I would like to have in SLE15-SP6, since it
> would facilitate a lot of future backports.
> 
> But in order to do it, it needs the backport of several other fixes,
> cleanups and refactorings. I've been doing it and so far there's really a
> lot of patches, some of them quite large, so far 50 patches, which are:
> 

<snipped> 

> 
> And this is SLE15-SP6.

This is quite a long list and the risk of adding so much code inadvertently introducing bugs is high. This is not worth a feature which we do not support.

> 
> What do we do about SLE15-SP5?
> 
> And can we get it clear if we are going to support btrfs on zoned devices
> for SLE15-SP6, or SP5? There are more CVE fixes for zoned mode coming in,
> and they depend on previous fixes we don't have. There's also quite a lot of
> zoned fixes coming in frequently upstream, and that requires extra work
> which is very hard to find time for, considering the swarm of other CVEs and
> non-CVE fixes.
> 
> Goldwyn?

Zoned devices is not supported for SLE15SP6. We will put a warning in btrfsprogs/mkfs to warn when the user creates a filesystem with zoned support.
Comment 10 Filipe Manana 2024-07-19 11:56:46 UTC
(In reply to Goldwyn Rodrigues from comment #9)
> (In reply to Filipe Manana from comment #8)
> > (In reply to Goldwyn Rodrigues from comment #7)
> > > I did a deeper check. The patch is relevant for v6.8 as indicated in the
> > 
> > Don't always guide by the version tagged in the CC stable line.
> > It's 6.8 because the backport is simple against 6.8 but complex and a lot of
> > work for anything below it (see below why).
> > 
> > > patch. The btrfs_block_group structure did not have physical_map variable,
> > 
> > Are you sure? Which branch were you looking at?
> > It exists in both SLE15-SP6 and SLE15-SP5, just like in upstream kernels 6.4
> > and 5.18.
> 
> Looks like I tried SLE15-SP5 and it does not have the physical_map variable.
> 
> > 
> > For SLE15-SP6:
> > 
> > https://github.com/SUSE/kernel/blob/SLE15-SP6/fs/btrfs/zoned.c#L1321
> > 
> > > access to which shows up in the stack trace.
> > > 
> > > I am not sure if dev_replace.rwsem will be of any help.
> > 
> > The use of the semaphore is precisely to have safe access to the
> > ->physical_map member of a block group.
> > 
> > The problem with this patch is that it has a lot of dependencies.
> > In SLE kernels the physical_map is not reference counted, and I don't see a
> > good way to solve it without making it reference counted, which happened in
> > the following large patch from upstream (landed in kernel 6.8):
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> > ?id=7dc66abb5a47778d7db327783a0ba172b8cff0b5
> > 
> > So adapting the fix to SLE15-SP6 without that change would result in code
> > very different from what we have upstream, and make future backports
> > diverging more and more.
> > 
> > Now that's an important change I would like to have in SLE15-SP6, since it
> > would facilitate a lot of future backports.
> > 
> > But in order to do it, it needs the backport of several other fixes,
> > cleanups and refactorings. I've been doing it and so far there's really a
> > lot of patches, some of them quite large, so far 50 patches, which are:
> > 
> 
> <snipped> 
> 
> > 
> > And this is SLE15-SP6.
> 
> This is quite a long list and the risk of adding so much code inadvertently
> introducing bugs is high. This is not worth a feature which we do not
> support.

Yes, but as I said in the team meeting, backporting all these (and now they are 64 patches), is a good thing to do because it makes the code much more close to upstream and facilitates backports of other fixes. That's why I have been spending the last few days working on the backports, which I've just pushed to git (branch users/fdmanana/SLE15-SP6/for-next).

> 
> > 
> > What do we do about SLE15-SP5?
> > 
> > And can we get it clear if we are going to support btrfs on zoned devices
> > for SLE15-SP6, or SP5? There are more CVE fixes for zoned mode coming in,
> > and they depend on previous fixes we don't have. There's also quite a lot of
> > zoned fixes coming in frequently upstream, and that requires extra work
> > which is very hard to find time for, considering the swarm of other CVEs and
> > non-CVE fixes.
> > 
> > Goldwyn?
> 
> Zoned devices is not supported for SLE15SP6. We will put a warning in
> btrfsprogs/mkfs to warn when the user creates a filesystem with zoned
> support.