Is this one a random one, or can be reliably reproduced?

IIRC even with upstream kernel, we still have a random chance to hit such qgroup rsv leaks.
If this one is reliably reproducible, it can be a very good case for us to debug.

(In reply to Wenruo Qu from comment #1)
> Is this one a random one, or can be reliably reproduced?

So far it's failed every single time.

> IIRC even with upstream kernel, we still have a random chance to hit such
> qgroup rsv leaks.
> If this one is reliably reproducible, it can be a very good case for us to
> debug.

It happens during boot in the initrd phase, so probably not the ideal situation...

This is part of TW Snapshot 20231013+. Just boot one of the MicroOS images with a supplied combustion config and it should trigger the error message.

*** Bug 1219201 has been marked as a duplicate of this bug. ***

(In reply to Fabian Vogt from comment #4)
> *** Bug 1219201 has been marked as a duplicate of this bug. ***

Any news here? Fails in ALP meanwhile.

(In reply to Fabian Vogt from comment #5)
> (In reply to Fabian Vogt from comment #4)
> > *** Bug 1219201 has been marked as a duplicate of this bug. ***
> 
> Any news here? Fails in ALP meanwhile.

There seems to be some activity in SLE Micro 6.0 bug:
https://bugzilla.suse.com/show_bug.cgi?id=1219199

My bad, I should take more care about this BZ earlier.
(And feel free to mark #1219199 as duplicated)

With the help of David, the possible cause is pinned down to the microos specific initramfs hooks (that SElinux relabling part).
But it's still pretty hard to reproduce if using the micros image (everything is read-only, pretty small disk, not enough development tools)

I'm wondering if it's possible for me to use openSUSE tumbleweed as the base, and just intall that micro os specific dracut hook to reproduce it?

Meanwhile, I have several upstream backport candidates which are not yet in our v6.4 branches, I will backport them soon and would it be possible to test the newer branches (without waiting for the proper fix)?
As if those backport fixes the problem, it would save us a lot of time to setup the reproducer initramfs.

If anyone can try the following branch and verify if it resolves the problem, it would be very helpful:

  users/wqu/SLE15-SP6/for-next

(In reply to Wenruo Qu from comment #9)
> My bad, I should take more care about this BZ earlier.
> (And feel free to mark #1219199 as duplicated)
> 
> With the help of David, the possible cause is pinned down to the microos
> specific initramfs hooks (that SElinux relabling part).
> But it's still pretty hard to reproduce if using the micros image
> (everything is read-only, pretty small disk, not enough development tools)

It's not the SELinux relabelling part, it's the whole

- mount /sysroot
- SELinux relabel
- Using transactional-update, create a new rootfs snapshot and do stuff with it
- umount /sysroot

And the umount triggers it. I guess it's the snapshot creation which triggers
it. It's basically the only place the root fs is actually unmounted except
during shutdown.

> I'm wondering if it's possible for me to use openSUSE tumbleweed as the
> base, and just intall that micro os specific dracut hook to reproduce it?

What are you issing from MicroOS? There shouldn't be significant differences.

On plain TW, there is no relabel and combustion uses plain snapper instead
of t-u, and the issue does not occur: https://openqa.opensuse.org/tests/3950956

> Meanwhile, I have several upstream backport candidates which are not yet in
> our v6.4 branches, I will backport them soon and would it be possible to
> test the newer branches (without waiting for the proper fix)?
> As if those backport fixes the problem, it would save us a lot of time to
> setup the reproducer initramfs.

It still happens on current TW, i.e. kernel 6.7.5:
https://openqa.opensuse.org/tests/3951060#step/journal_check/21

(In reply to Wenruo Qu from comment #10)
> If anyone can try the following branch and verify if it resolves the
> problem, it would be very helpful:
> 
>   users/wqu/SLE15-SP6/for-next

Do you have a build in OBS or IBS? That way I could easily build an image with it.

(In reply to Fabian Vogt from comment #11)
> (In reply to Wenruo Qu from comment #9)
> > My bad, I should take more care about this BZ earlier.
> > (And feel free to mark #1219199 as duplicated)
> > 
> > With the help of David, the possible cause is pinned down to the microos
> > specific initramfs hooks (that SElinux relabling part).
> > But it's still pretty hard to reproduce if using the micros image
> > (everything is read-only, pretty small disk, not enough development tools)
> 
> It's not the SELinux relabelling part, it's the whole
> 
> - mount /sysroot
> - SELinux relabel
> - Using transactional-update, create a new rootfs snapshot and do stuff with
> it

The problem is, from the duplicated report, the leak happens on @/var subvolume,
not sure if it's one-time or with randomness involved.

> - umount /sysroot
> 
> And the umount triggers it. I guess it's the snapshot creation which triggers
> it. It's basically the only place the root fs is actually unmounted except
> during shutdown.

Snapshot creation doesn't seem to cause the problem.
As our regular fstests includes fsstress, which would create snapshot/subvolume.

I'm suspecting the subvolume ro->rw and rw->ro switching, as that is not included
in fsstress workload.

> 
> > I'm wondering if it's possible for me to use openSUSE tumbleweed as the
> > base, and just intall that micro os specific dracut hook to reproduce it?
> 
> What are you issing from MicroOS? There shouldn't be significant differences.

The SLEM has its rootfs set to RO, I'm not sure if it's designed to be so or not.
(Sorry, spend most of my time on upstream, thus really unfamiliar with SLE product
lines)

> 
> On plain TW, there is no relabel and combustion uses plain snapper instead
> of t-u, and the issue does not occur:
> https://openqa.opensuse.org/tests/3950956
> 
> > Meanwhile, I have several upstream backport candidates which are not yet in
> > our v6.4 branches, I will backport them soon and would it be possible to
> > test the newer branches (without waiting for the proper fix)?
> > As if those backport fixes the problem, it would save us a lot of time to
> > setup the reproducer initramfs.
> 
> It still happens on current TW, i.e. kernel 6.7.5:
> https://openqa.opensuse.org/tests/3951060#step/journal_check/21

OK, this TW result helps a lot, it means it's a new cases we don't have coverage at all.

Let me find a way to setup an environment allowing me to tinker the kernel code and
generate an initramfs with needed hooks.

Any good advice on setting an easy to reproduce environmen?

(My daily drive testing VM is not even deb/rpm based, nor using dracut to generate an
 initramfs, although I have all the infrastructure to testing kernel easily, I don't
 have a good plan to testing it with dracut generated initramfs.)
> 
> (In reply to Wenruo Qu from comment #10)
> > If anyone can try the following branch and verify if it resolves the
> > problem, it would be very helpful:
> > 
> >   users/wqu/SLE15-SP6/for-next
> 
> Do you have a build in OBS or IBS? That way I could easily build an image
> with it.

I think it's already merged into the latest SLE15-SP6 kernel-source.
But I don't think it's going to solve the problem.

Although I can reproduce the bug using the SLE based (6.4 kernel) MicroOS, I failed to reproduce it with opensuse based microos as I can not make the initramfs to do the 98selinux-microos hook.

I tried using "rd.autorelabel" kernel cmdline, tried going into a writeable shell to remove "/etc/selinux/.relabelled" and create "/etc/selinux/.autorelabel".
Neither way can force the initramfs to trigger the hook of 98selinux-microos.

I'll retry the workload on another system but without using the initramfs (aka, run the script independent with enough modification).

Created attachment 872915 [details]
Independent relabaling

I extract the work of the relabling and run it with SLE v6.4 kernel (beyond rpm-6.4.0-150600.7 tag).

Unfortunately I can not reproduce it in 16 runs.

The script is mostly the same as the relabel workload, with minor changes:

- Only "unmount -R" for the root mount point once
  As I'm using Fedora Aarch64, it's unmount with "-R" wound unmount all children and
  the mount point.

- Use a opensuse-microos qcow2 image as /dev/vdd

So I don't believe it's really the relabling nor the subvolume ro->rw/rw->ro change causing the problem.

If anyone can have a more detailed info on all the hooks executed on the ${newroot}, it would help a lot for me to reproduce and debug.

BTW, I also checked the whole initramfs filesystem.
The dracut hooks are very limited, and I don't believe there are anything else btrfs related, except `50-selinux-microos-relabel.sh` and `90-health-checker-emergency.sh`.

```
initramfs/lib/dracut/hooks$ ls -R
.:
cleanup  cmdline  emergency  initqueue  mount  netroot  pre-mount  pre-pivot  pre-shutdown  pre-trigger  pre-udev  shutdown  shutdown-emergency
./cleanup:
90-cleanup-fcoe.sh  90-cleanup-iscsi.sh  99-mdraid-needshutdown.sh  99-nfsroot-cleanup.sh
./cmdline:
00-parse-root.sh      30-parse-crypt.sh    30-parse-lvm.sh        90-parse-nfsroot.sh  95-parse-virtfs.sh    99-nm-config.sh   99-parse-suse-initrd.sh
20-parse-uefifcoe.sh  30-parse-lunmask.sh  90-parse-iscsiroot.sh  91-dhcp-root.sh      95-parse-virtiofs.sh  99-parse-fcoe.sh
./emergency:
90-health-checker-emergency.sh
./initqueue:
finished  online  settled  timeout
./initqueue/finished:
./initqueue/online:
./initqueue/settled:
99-nm-run.sh
./initqueue/timeout:
99-rootfallback.sh
./mount:
99-mount-virtfs.sh
./netroot:
./pre-mount:
10-mdraid-waitclean.sh  20-kiwi-repart-disk.sh  99-mount-virtiofs.sh
./pre-pivot:
50-selinux-microos-relabel.sh
./pre-shutdown:
30-mdmon-pre-shutdown.sh
./pre-trigger:
01-load-modsign-keys.sh  03-lldpad.sh  30-parse-md.sh
./pre-udev:
30-dm-pre-udev.sh  30-mdmon-pre-udev.sh  50-ifname-genrules.sh  99-nfs-start-rpc.sh
./shutdown:
25-dm-shutdown.sh  30-md-shutdown.sh  40-stop-fcoe.sh
./shutdown-emergency:
```

So unfortunately I really run out of ideas to properly debug/reproduce the leak.
Any help would be very appreciated.

I have finally reproduced the bug, using a microos rootfs. Just as Fabian's result, relabeling is not the root cause.
The cause seems to be related the snapshot usage caused by transactional-update, and maybe have overlayfs involved.

The setup procedure looks like this:

```
#!/bin/bash

root="/dev/vdc2"  # MicroOS rootfs
var="/dev/vdc3"   # MicorOs /var

mnt="/mnt/data"

umount -R $mnt &> /dev/null
umount $root &> /dev/null
umount $var &> /dev/null

mount $root $mnt
mount $var $mnt/var
mount $root -o subvol=/@/.snapshots $mnt/.snapshots
```
Then arch-chroot into $mnt, and run `transactional-update shell` to get a RW shell.
Inside that shell, just touch a file inside /etc. then "umount -R $mnt" would trigger the error.

Furthermore, with the leakage, btrfs-quota number would be corrupted for the latest created snapshots (including the 1/0 qgroup).
So this is not just a leakage, but `transactional-update` is using btrfs in a way that exposed one big btrfs qgroup bug (or invalid but not rejected use-case).

Let me look into the transactional-update script to see what they're really doing and further shrink down the reproducer.

Root cause pinned down.

The problem is caused by the fact that, microos (maybe it's just plain snapper?) is putting all the snapshots into a higher level qgroup 1/0.

However due to the nature of qgroup extent tracing, creating a snapshot with higher level qgroup would immediately mark the qgroup inconsistent.
This is because we need to fully rescan the snapshot source and new snapshot to fully understand the ownership of each subvolume.

Marking qgroup inconsistent is not a big deal, but in recent kernel, we introduced a new qgroup state, which would skip all qgroup accounting but still keep qgroup relationship accurate.
This is to allow btrfs qgroup rescan to correctly rebuild the new numbers without rebuilding the relationship.

However there is a bug in the accounting skip part, which should only skip the accounting, but in fact it also skips the qgroup reservation code, causing the leak.

The fix is pretty simple, but I really want to tell the microOS and snapper team, please do not use higher level qgroup (aka, that 1/0), especially if you're creating snapshot and assigned it into that 1/0 qgroup.
It would immediately mark the qgroup inconsistent, meaning for whatever reason (I guess to calculate how many bytes can be reclaimed when deleting those snapshots), qgroup won't help anyway until a rescan is done.
And for microOS cases, the amount of snapshots are pretty high, causing tons of shared extents, making rescan super slow.

So in short, DO NOT use 1/0 qgroup especially for microOS!!

(In reply to Wenruo Qu from comment #19)
> So in short, DO NOT use 1/0 qgroup especially for microOS!!

That's indeed just how snapper sets up qgroups. Adding needinfo on arvin.

FYI, we see this bug in SL-Micro 6 Build 10.2 in openQA: https://openqa.suse.de/tests/14113992#step/disk_boot/3

Kernel version is 6.4.0-14-default.

(In reply to Felix Niederwanger from comment #30)
> FYI, we see this bug in SL-Micro 6 Build 10.2 in openQA:
> https://openqa.suse.de/tests/14113992#step/disk_boot/3
> 
> Kernel version is 6.4.0-14-default.

https://bugzilla.suse.com/show_bug.cgi?id=1219201

I'm still downloading the image (it's only ~100KiB/s here).

Meanwhile can anyone provide the following output from the latest SLEM build?

```
rpm -qip kernel.rpm | grep GIT
```

Which should include the build git hash from kernel-source repo, so that I can verify if the fix is included, or there is something else.

Finally got the image downloaded.

The kernel package (kernel-default-6.4.0-14.1) is using commit 21c6bc6a from kernel-source.
And unfortunately (and fortunately to me), that tag does not contain the fix yet.

So SLEM needs to wait for the next rpm tag to get the fix included.

(In reply to Fabian Vogt from comment #21)
> (In reply to Wenruo Qu from comment #19)
> > So in short, DO NOT use 1/0 qgroup especially for microOS!!
> 
> That's indeed just how snapper sets up qgroups. Adding needinfo on arvin.

snapper sets qgroups up with the command 'snapper setup-quota'. So if
qgroups should not be used simply do not run that command. Tools
generating images might setup quota manually (without snapper).

SUSE-SU-2024:2135-1: An update that solves 428 vulnerabilities, contains 15 features and has 78 security fixes can now be installed.

Category: security (important)
Bug References: 1012628, 1065729, 1181674, 1187716, 1193599, 1194869, 1207948, 1208593, 1209657, 1213573, 1214852, 1215199, 1216196, 1216358, 1216702, 1217169, 1217384, 1217408, 1217489, 1217750, 1217959, 1218205, 1218336, 1218447, 1218562, 1218779, 1218917, 1219104, 1219170, 1219596, 1219623, 1219834, 1220021, 1220045, 1220120, 1220148, 1220328, 1220342, 1220428, 1220430, 1220569, 1220587, 1220738, 1220783, 1220915, 1221044, 1221276, 1221293, 1221303, 1221375, 1221504, 1221612, 1221615, 1221635, 1221645, 1221649, 1221765, 1221777, 1221783, 1221816, 1221829, 1221830, 1221858, 1222115, 1222173, 1222264, 1222273, 1222294, 1222301, 1222303, 1222304, 1222307, 1222357, 1222366, 1222368, 1222371, 1222378, 1222379, 1222385, 1222422, 1222426, 1222428, 1222437, 1222445, 1222459, 1222464, 1222489, 1222522, 1222525, 1222527, 1222531, 1222532, 1222549, 1222550, 1222557, 1222559, 1222563, 1222585, 1222586, 1222596, 1222606, 1222608, 1222613, 1222615, 1222618, 1222622, 1222624, 1222627, 1222630, 1222635, 1222721, 1222727, 1222769, 1222771, 1222772, 1222775, 1222777, 1222780, 1222782, 1222793, 1222799, 1222801, 1222968, 1223007, 1223011, 1223015, 1223016, 1223020, 1223023, 1223024, 1223030, 1223033, 1223034, 1223035, 1223038, 1223039, 1223041, 1223045, 1223046, 1223051, 1223052, 1223058, 1223060, 1223061, 1223076, 1223077, 1223084, 1223111, 1223113, 1223138, 1223143, 1223187, 1223189, 1223190, 1223191, 1223198, 1223202, 1223285, 1223315, 1223338, 1223369, 1223380, 1223384, 1223390, 1223439, 1223462, 1223532, 1223539, 1223575, 1223590, 1223591, 1223592, 1223593, 1223625, 1223628, 1223629, 1223633, 1223634, 1223637, 1223641, 1223643, 1223649, 1223650, 1223651, 1223652, 1223653, 1223654, 1223655, 1223660, 1223661, 1223663, 1223664, 1223665, 1223666, 1223668, 1223669, 1223670, 1223671, 1223675, 1223677, 1223678, 1223686, 1223692, 1223693, 1223695, 1223696, 1223698, 1223705, 1223712, 1223718, 1223728, 1223732, 1223735, 1223739, 1223741, 1223744, 1223745, 1223747, 1223748, 1223749, 1223750, 1223752, 1223754, 1223757, 1223759, 1223761, 1223762, 1223774, 1223782, 1223787, 1223788, 1223789, 1223790, 1223802, 1223805, 1223810, 1223822, 1223827, 1223831, 1223834, 1223838, 1223869, 1223870, 1223871, 1223872, 1223874, 1223944, 1223945, 1223946, 1223991, 1224076, 1224096, 1224098, 1224099, 1224137, 1224166, 1224174, 1224177, 1224180, 1224181, 1224331, 1224348, 1224423, 1224429, 1224430, 1224432, 1224433, 1224437, 1224438, 1224442, 1224443, 1224445, 1224449, 1224477, 1224479, 1224480, 1224481, 1224482, 1224486, 1224487, 1224488, 1224491, 1224492, 1224493, 1224494, 1224495, 1224500, 1224501, 1224502, 1224504, 1224505, 1224506, 1224507, 1224508, 1224509, 1224511, 1224513, 1224517, 1224519, 1224521, 1224524, 1224525, 1224526, 1224530, 1224531, 1224534, 1224537, 1224541, 1224542, 1224543, 1224546, 1224550, 1224552, 1224553, 1224555, 1224557, 1224558, 1224559, 1224562, 1224565, 1224566, 1224567, 1224568, 1224569, 1224571, 1224573, 1224576, 1224577, 1224578, 1224579, 1224580, 1224581, 1224582, 1224585, 1224586, 1224587, 1224588, 1224592, 1224596, 1224598, 1224600, 1224601, 1224602, 1224603, 1224605, 1224607, 1224608, 1224609, 1224611, 1224613, 1224615, 1224617, 1224618, 1224620, 1224621, 1224622, 1224623, 1224624, 1224626, 1224627, 1224628, 1224629, 1224630, 1224632, 1224633, 1224634, 1224636, 1224637, 1224638, 1224639, 1224640, 1224643, 1224644, 1224645, 1224646, 1224647, 1224648, 1224649, 1224650, 1224651, 1224652, 1224653, 1224654, 1224657, 1224660, 1224663, 1224664, 1224665, 1224666, 1224667, 1224668, 1224671, 1224672, 1224674, 1224675, 1224676, 1224677, 1224678, 1224679, 1224680, 1224681, 1224682, 1224683, 1224685, 1224686, 1224687, 1224688, 1224692, 1224696, 1224697, 1224699, 1224701, 1224703, 1224704, 1224705, 1224706, 1224707, 1224709, 1224710, 1224712, 1224714, 1224716, 1224717, 1224718, 1224719, 1224720, 1224721, 1224722, 1224723, 1224725, 1224727, 1224728, 1224729, 1224730, 1224731, 1224732, 1224733, 1224736, 1224738, 1224739, 1224740, 1224741, 1224742, 1224747, 1224749, 1224763, 1224764, 1224765, 1224766, 1224790, 1224792, 1224793, 1224803, 1224804, 1224866, 1224936, 1224989, 1225007, 1225053, 1225133, 1225134, 1225136, 1225172, 1225502, 1225578, 1225579, 1225580, 1225593, 1225605, 1225607, 1225610, 1225616, 1225618, 1225640, 1225642, 1225692, 1225694, 1225695, 1225696, 1225698, 1225699, 1225704, 1225705, 1225708, 1225710, 1225712, 1225714, 1225715, 1225720, 1225722, 1225728, 1225734, 1225735, 1225736, 1225747, 1225748, 1225749, 1225750, 1225756, 1225765, 1225766, 1225769, 1225773, 1225775, 1225842, 1225945
CVE References: CVE-2023-0160, CVE-2023-47233, CVE-2023-52434, CVE-2023-52458, CVE-2023-52463, CVE-2023-52472, CVE-2023-52483, CVE-2023-52492, CVE-2023-52503, CVE-2023-52591, CVE-2023-52608, CVE-2023-52616, CVE-2023-52618, CVE-2023-52631, CVE-2023-52635, CVE-2023-52640, CVE-2023-52641, CVE-2023-52645, CVE-2023-52652, CVE-2023-52653, CVE-2023-52654, CVE-2023-52655, CVE-2023-52657, CVE-2023-52658, CVE-2023-52659, CVE-2023-52660, CVE-2023-52661, CVE-2023-52662, CVE-2023-52663, CVE-2023-52664, CVE-2023-52667, CVE-2023-52669, CVE-2023-52670, CVE-2023-52671, CVE-2023-52673, CVE-2023-52674, CVE-2023-52675, CVE-2023-52676, CVE-2023-52678, CVE-2023-52679, CVE-2023-52680, CVE-2023-52681, CVE-2023-52683, CVE-2023-52685, CVE-2023-52686, CVE-2023-52687, CVE-2023-52690, CVE-2023-52691, CVE-2023-52692, CVE-2023-52693, CVE-2023-52694, CVE-2023-52695, CVE-2023-52696, CVE-2023-52697, CVE-2023-52698, CVE-2023-52771, CVE-2023-52772, CVE-2023-52860, CVE-2023-52882, CVE-2023-6238, CVE-2023-6270, CVE-2023-6531, CVE-2023-7042, CVE-2024-0639, CVE-2024-21823, CVE-2024-22099, CVE-2024-23848, CVE-2024-24861, CVE-2024-25739, CVE-2024-26601, CVE-2024-26611, CVE-2024-26614, CVE-2024-26632, CVE-2024-26638, CVE-2024-26642, CVE-2024-26643, CVE-2024-26652, CVE-2024-26654, CVE-2024-26656, CVE-2024-26657, CVE-2024-26671, CVE-2024-26673, CVE-2024-26674, CVE-2024-26675, CVE-2024-26679, CVE-2024-26684, CVE-2024-26685, CVE-2024-26692, CVE-2024-26696, CVE-2024-26697, CVE-2024-26704, CVE-2024-26714, CVE-2024-26726, CVE-2024-26731, CVE-2024-26733, CVE-2024-26736, CVE-2024-26737, CVE-2024-26739, CVE-2024-26740, CVE-2024-26742, CVE-2024-26756, CVE-2024-26757, CVE-2024-26760, CVE-2024-267600, CVE-2024-26761, CVE-2024-26764, CVE-2024-26769, CVE-2024-26772, CVE-2024-26773, CVE-2024-26774, CVE-2024-26775, CVE-2024-26779, CVE-2024-26783, CVE-2024-26786, CVE-2024-26791, CVE-2024-26793, CVE-2024-26794, CVE-2024-26802, CVE-2024-26805, CVE-2024-26807, CVE-2024-26815, CVE-2024-26816, CVE-2024-26822, CVE-2024-26828, CVE-2024-26832, CVE-2024-26836, CVE-2024-26844, CVE-2024-26846, CVE-2024-26848, CVE-2024-26853, CVE-2024-26854, CVE-2024-26855, CVE-2024-26856, CVE-2024-26857, CVE-2024-26858, CVE-2024-26860, CVE-2024-26861, CVE-2024-26862, CVE-2024-26866, CVE-2024-26868, CVE-2024-26870, CVE-2024-26878, CVE-2024-26881, CVE-2024-26882, CVE-2024-26883, CVE-2024-26884, CVE-2024-26885, CVE-2024-26898, CVE-2024-26899, CVE-2024-26900, CVE-2024-26901, CVE-2024-26903, CVE-2024-26906, CVE-2024-26909, CVE-2024-26921, CVE-2024-26922, CVE-2024-26923, CVE-2024-26925, CVE-2024-26928, CVE-2024-26932, CVE-2024-26933, CVE-2024-26934, CVE-2024-26935, CVE-2024-26937, CVE-2024-26938, CVE-2024-26940, CVE-2024-26943, CVE-2024-26945, CVE-2024-26946, CVE-2024-26948, CVE-2024-26949, CVE-2024-26950, CVE-2024-26951, CVE-2024-26956, CVE-2024-26957, CVE-2024-26958, CVE-2024-26960, CVE-2024-26961, CVE-2024-26962, CVE-2024-26963, CVE-2024-26964, CVE-2024-26972, CVE-2024-26973, CVE-2024-26978, CVE-2024-26979, CVE-2024-26981, CVE-2024-26982, CVE-2024-26983, CVE-2024-26984, CVE-2024-26986, CVE-2024-26988, CVE-2024-26989, CVE-2024-26990, CVE-2024-26991, CVE-2024-26992, CVE-2024-26993, CVE-2024-26994, CVE-2024-26995, CVE-2024-26996, CVE-2024-26997, CVE-2024-26999, CVE-2024-27000, CVE-2024-27001, CVE-2024-27002, CVE-2024-27003, CVE-2024-27004, CVE-2024-27008, CVE-2024-27013, CVE-2024-27014, CVE-2024-27022, CVE-2024-27027, CVE-2024-27028, CVE-2024-27029, CVE-2024-27030, CVE-2024-27031, CVE-2024-27036, CVE-2024-27046, CVE-2024-27056, CVE-2024-27057, CVE-2024-27062, CVE-2024-27067, CVE-2024-27080, CVE-2024-27388, CVE-2024-27389, CVE-2024-27393, CVE-2024-27395, CVE-2024-27396, CVE-2024-27398, CVE-2024-27399, CVE-2024-27400, CVE-2024-27401, CVE-2024-27405, CVE-2024-27408, CVE-2024-27410, CVE-2024-27411, CVE-2024-27412, CVE-2024-27413, CVE-2024-27416, CVE-2024-27417, CVE-2024-27418, CVE-2024-27431, CVE-2024-27432, CVE-2024-27434, CVE-2024-27435, CVE-2024-27436, CVE-2024-35784, CVE-2024-35786, CVE-2024-35788, CVE-2024-35789, CVE-2024-35790, CVE-2024-35791, CVE-2024-35794, CVE-2024-35795, CVE-2024-35796, CVE-2024-35799, CVE-2024-35800, CVE-2024-35801, CVE-2024-35803, CVE-2024-35804, CVE-2024-35806, CVE-2024-35808, CVE-2024-35809, CVE-2024-35810, CVE-2024-35811, CVE-2024-35812, CVE-2024-35813, CVE-2024-35814, CVE-2024-35815, CVE-2024-35817, CVE-2024-35819, CVE-2024-35821, CVE-2024-35822, CVE-2024-35823, CVE-2024-35824, CVE-2024-35825, CVE-2024-35828, CVE-2024-35829, CVE-2024-35830, CVE-2024-35833, CVE-2024-35834, CVE-2024-35835, CVE-2024-35836, CVE-2024-35837, CVE-2024-35838, CVE-2024-35841, CVE-2024-35842, CVE-2024-35845, CVE-2024-35847, CVE-2024-35849, CVE-2024-35850, CVE-2024-35851, CVE-2024-35852, CVE-2024-35854, CVE-2024-35860, CVE-2024-35861, CVE-2024-35862, CVE-2024-35863, CVE-2024-35864, CVE-2024-35865, CVE-2024-35866, CVE-2024-35867, CVE-2024-35868, CVE-2024-35869, CVE-2024-35870, CVE-2024-35872, CVE-2024-35875, CVE-2024-35877, CVE-2024-35878, CVE-2024-35879, CVE-2024-35883, CVE-2024-35885, CVE-2024-35887, CVE-2024-35889, CVE-2024-35891, CVE-2024-35895, CVE-2024-35901, CVE-2024-35903, CVE-2024-35904, CVE-2024-35905, CVE-2024-35907, CVE-2024-35909, CVE-2024-35911, CVE-2024-35912, CVE-2024-35914, CVE-2024-35915, CVE-2024-35916, CVE-2024-35917, CVE-2024-35921, CVE-2024-35922, CVE-2024-35924, CVE-2024-35927, CVE-2024-35928, CVE-2024-35930, CVE-2024-35931, CVE-2024-35932, CVE-2024-35933, CVE-2024-35935, CVE-2024-35936, CVE-2024-35937, CVE-2024-35938, CVE-2024-35940, CVE-2024-35943, CVE-2024-35944, CVE-2024-35945, CVE-2024-35946, CVE-2024-35947, CVE-2024-35950, CVE-2024-35951, CVE-2024-35952, CVE-2024-35953, CVE-2024-35954, CVE-2024-35955, CVE-2024-35956, CVE-2024-35958, CVE-2024-35959, CVE-2024-35960, CVE-2024-35961, CVE-2024-35963, CVE-2024-35964, CVE-2024-35965, CVE-2024-35966, CVE-2024-35967, CVE-2024-35969, CVE-2024-35971, CVE-2024-35972, CVE-2024-35973, CVE-2024-35974, CVE-2024-35975, CVE-2024-35977, CVE-2024-35978, CVE-2024-35981, CVE-2024-35982, CVE-2024-35984, CVE-2024-35986, CVE-2024-35989, CVE-2024-35990, CVE-2024-35991, CVE-2024-35992, CVE-2024-35995, CVE-2024-35997, CVE-2024-35999, CVE-2024-36002, CVE-2024-36006, CVE-2024-36007, CVE-2024-36009, CVE-2024-36011, CVE-2024-36012, CVE-2024-36013, CVE-2024-36014, CVE-2024-36015, CVE-2024-36016, CVE-2024-36018, CVE-2024-36019, CVE-2024-36020, CVE-2024-36021, CVE-2024-36025, CVE-2024-36026, CVE-2024-36029, CVE-2024-36030, CVE-2024-36032, CVE-2024-36880, CVE-2024-36885, CVE-2024-36890, CVE-2024-36891, CVE-2024-36893, CVE-2024-36894, CVE-2024-36895, CVE-2024-36896, CVE-2024-36897, CVE-2024-36898, CVE-2024-36906, CVE-2024-36918, CVE-2024-36921, CVE-2024-36922, CVE-2024-36928, CVE-2024-36930, CVE-2024-36931, CVE-2024-36936, CVE-2024-36940, CVE-2024-36941, CVE-2024-36942, CVE-2024-36944, CVE-2024-36947, CVE-2024-36949, CVE-2024-36950, CVE-2024-36951, CVE-2024-36955, CVE-2024-36959
Jira References: PED-3184, PED-3311, PED-3535, PED-4486, PED-4593, PED-5062, PED-542, PED-5728, PED-5853, PED-6079, PED-6252, PED-7542, PED-7619, PED-8111, PED-8240
Maintenance Incident: [SUSE:Maintenance:34127](https://smelt.suse.de/incident/34127/)
Sources used:
openSUSE Leap 15.6 (src):
 kernel-syms-azure-6.4.0-150600.8.5.1, kernel-source-azure-6.4.0-150600.8.5.4
Public Cloud Module 15-SP6 (src):
 kernel-syms-azure-6.4.0-150600.8.5.1, kernel-source-azure-6.4.0-150600.8.5.4

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.