Bug 1180749 - AMD Ryzen 4800H Renoir APU brightness control not working as found in some Lenovo Legion 5 15ARH05
AMD Ryzen 4800H Renoir APU brightness control not working as found in some Le...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
x86-64 openSUSE Tumbleweed
: P3 - Medium : Normal (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
https://gitlab.freedesktop.org/drm/am...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-01-10 18:26 UTC by Antony J.R
Modified: 2022-07-21 19:25 UTC (History)
5 users (show)

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


Attachments
Fix brightness sysfs value read for aux backlight (2.07 KB, patch)
2021-02-03 12:29 UTC, Takashi Iwai
Details | Diff
Patch to add aux_backlight module option to amdgpu driver (2.78 KB, patch)
2021-02-03 12:30 UTC, Takashi Iwai
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Antony J.R 2021-01-10 18:26:37 UTC
When using switchable graphics in Lenovo Legion 5 15ARH05, the AMD Renoir APU works along with NVIDIA Graphics(even non-free and prime works) but the brightness cannot be controlled by the Fn keys, Software or /sys/class/backlight

I've tried setting all the kernel params like acpi_backlight=vender or native but the brightness control still does not work.

I highly suspect it's a bug in the amdgpu kernel driver. For now nvidia graphics card works with brightness control.

It is also worthy to note that cat /sys/class/backlight/*/actual_brightness always returns 311 and does not change even when executed echo 50 > /sys/class/backlight/*/brightness

There are number of reports on this issue over the internet but nothing official. I've tried a lot of linux distros and none of them work and it seems it is broken even in the mainline kernel. I've also tried Kernel:HEAD version of the kernel without the nvidia graphics support but still the brightness control does not work. At the time writing I've booted linux 5.11-rc2 but the brightness control still does not work.
Comment 1 Takashi Iwai 2021-01-11 12:59:51 UTC
Care to report to the upstream, e.g. gitlab.freedsktop.org Issues?
That's the official place for reporting.  I'll keep this bug opened in case we can do some backports based on the upstream devs.
Comment 2 Antony J.R 2021-01-11 13:51:24 UTC
(In reply to Takashi Iwai from comment #1)
> Care to report to the upstream, e.g. gitlab.freedsktop.org Issues?
> That's the official place for reporting.  I'll keep this bug opened in case
> we can do some backports based on the upstream devs.

I thought this is a bug with the amdgpu and radeon drivers in the linux kernel, is it not the case?? So it is a X.Org thing?

I'm a bit confused here. But I will try to talk with freedesktop folks.
Comment 3 Antony J.R 2021-01-11 14:30:47 UTC
Okay I can confirm that Fedora 32 with Linux Kernel version 5.6.6-300.fc32.x86_64  x86_64 GNU/Linux I can control the screen brightness but I can't do the workaround for the touchpad.

But in this version of the kernel we have cat /sys/class/backlight/*/actual_brightness constantly stuck to 2827 or something but still the brightness control works as expected. 

Did not try using the nvidia non-free drivers this one.

So I highly suspect that something happened between 5.6.6 and the mainline kernel.
Comment 4 Takashi Iwai 2021-01-11 14:40:35 UTC
(In reply to Antony J.R from comment #2)
> (In reply to Takashi Iwai from comment #1)
> > Care to report to the upstream, e.g. gitlab.freedsktop.org Issues?
> > That's the official place for reporting.  I'll keep this bug opened in case
> > we can do some backports based on the upstream devs.
> 
> I thought this is a bug with the amdgpu and radeon drivers in the linux
> kernel, is it not the case?? So it is a X.Org thing?

gitlab.freedesktop.org also the place where the kernel graphics guys use as the primary development place in general.  Use DRI/AMDGPU or such component there.
Comment 5 Takashi Iwai 2021-01-11 14:44:21 UTC
Actually, which backlight drivers are being used there?  Is it only ACPI or native driver?

And do I understand correctly that, if you switch to Nvidia driver (both mod setting and rendering), the backlight control works via /sys/class/backlight, while the same doesn't work if switching to AMDGPU?
Comment 6 Antony J.R 2021-01-11 14:52:50 UTC
(In reply to Takashi Iwai from comment #5)
> Actually, which backlight drivers are being used there?  Is it only ACPI or
> native driver?
> 
> And do I understand correctly that, if you switch to Nvidia driver (both mod
> setting and rendering), the backlight control works via
> /sys/class/backlight, while the same doesn't work if switching to AMDGPU?

To be exact, hybrid graphics brightness control does not work. Yes using only the discrete graphics card with nvidia non-free software enables me to control the backlight. But when switched to hybrid graphics(switchable graphics) the iGPU brightness control will not work.
Comment 7 Antony J.R 2021-01-11 14:56:18 UTC
With hybrid graphics disabled I have only /sys/class/backlight/nvidia_0 and brightness works correctly. But with hybrid graphics I have both /sys/class/backlight/amdgpu_bl0 and /sys/class/backlight/nvidia_0 . I can offload stuff to Nvidia graphics card and verify it with nvidia-smi but the brightness control is solely on the iGPU i.e in my case iGPU which is a Radeon graphics. This is known as Nvidia PRIME IIRC.
Comment 8 Takashi Iwai 2021-01-11 15:11:05 UTC
OK, then this sounds like a bug in amdgpu, indeed.  If so, gitlab.freedesktop.org is the right place to report.  Please go ahead :)
Comment 9 Antony J.R 2021-01-11 15:18:05 UTC
(In reply to Takashi Iwai from comment #8)
> OK, then this sounds like a bug in amdgpu, indeed.  If so,
> gitlab.freedesktop.org is the right place to report.  Please go ahead :)

Okay I've reported it to the upstream -> https://gitlab.freedesktop.org/drm/amd/-/issues/1438
Comment 10 Antony J.R 2021-02-01 22:27:28 UTC
I tested kernel version 5.11-rc6 from Kernel:HEAD and the brightness issue still exists. It seems like I should mainline this thing myself. Never expected this from amd, even NVIDIA drivers works great.
Comment 11 Antony J.R 2021-02-02 13:56:30 UTC
Kernel bug https://bugzilla.kernel.org/show_bug.cgi?id=203905
Comment 12 Takashi Iwai 2021-02-02 14:48:27 UTC
(In reply to Antony J.R from comment #11)
> Kernel bug https://bugzilla.kernel.org/show_bug.cgi?id=203905

I'm afraid that the above is a bit different issue.
The fix for the scaling problem was already included in 5.9 kernel.

We need starting the debug locally, at least to see what values are floating around there.
Comment 13 Takashi Iwai 2021-02-02 16:23:24 UTC
I'm building an amdgpu KMP with a debug print patch, targeted for Tumbleweed kernel.  Could you try the amdgpu-dbg-kmp-default from OBS home:tiwai:bsc1180749 repo, and give the dmesg output?
Comment 14 Antony J.R 2021-02-02 20:31:42 UTC
(In reply to Takashi Iwai from comment #13)
> I'm building an amdgpu KMP with a debug print patch, targeted for Tumbleweed
> kernel.  Could you try the amdgpu-dbg-kmp-default from OBS
> home:tiwai:bsc1180749 repo, and give the dmesg output?

Okay I've installed your package and rebooted with switchable graphics enabled, all the required logs are uploaded here -> https://github.com/antony-jr/lenovo-legion5-15arh05-scripts/tree/main/AMDGPUDebug

Also here is a very similar kernel bug -> https://bugzilla.kernel.org/show_bug.cgi?id=207833
Comment 15 Takashi Iwai 2021-02-02 20:36:37 UTC
Hm there is no added debug message.  Could you rebuild initrd (e.g. run mkinitrd) and retest?
Comment 16 Takashi Iwai 2021-02-02 20:37:57 UTC
Also, check the output of "modinfo amdgpu" after installing KMP.
The File section should show the directory with /lib/modules/.../updates/
Comment 17 Antony J.R 2021-02-02 21:00:55 UTC
(In reply to Takashi Iwai from comment #15)
> Hm there is no added debug message.  Could you rebuild initrd (e.g. run
> mkinitrd) and retest?

mkinitrd did the trick but now sddm does not start automatically for some reason so I have to do startx from tty but I can rollback.

The updated log is in the same location -> https://github.com/antony-jr/lenovo-legion5-15arh05-scripts/blob/main/AMDGPUDebug/dmesg.txt

For more debug info I tried to decrease the brightness to 0% and go to 100% again, hope that helps.
Comment 18 Takashi Iwai 2021-02-02 22:49:48 UTC
Thanks.  It shows that aux is used for the backlight control, and the values set there look OK through a quick glance.  While you tested the brightness, it didn't change actually, right?

Could you try to read the current brightness, and check the kernel log, too?
Comment 19 Antony J.R 2021-02-03 05:51:26 UTC
(In reply to Takashi Iwai from comment #18)
> Thanks.  It shows that aux is used for the backlight control, and the values
> set there look OK through a quick glance.  While you tested the brightness,
> it didn't change actually, right?
> 
> Could you try to read the current brightness, and check the kernel log, too?

Sorry for the late reply, the updated log is here => https://github.com/antony-jr/lenovo-legion5-15arh05-scripts/blob/main/AMDGPUDebug/dmesg.txt


I changed the brightness and did cat /sys/class/backlight/amdgpu_bl1/brightness and /sys/class/backlight/amdgpu_bl1/actual_brightness

Here the brightness changed when changed the brightness but actual_brightness is stuck at 311 constantly.

The kernel log also shows that the get brightness routine output is stuck at invalid values.
Comment 20 Takashi Iwai 2021-02-03 07:30:53 UTC
Thanks.  Then I misunderstood situation as if the backlight control didn't take any effect.

Now I refreshed the OBS KMP repo to contain the possible fix.  It's being rebuilt, and please give it a try later.  The rpm changelog should contain the entry like:
- Add a proper fix (attempt):
  0001-drm-amd-display-Fix-the-brightness-read-via-aux.patch

At first, uninstall the previous KMP, just do "zypper rm amdgpu-dbg-kmp-default"
Then re-install the new rpm, run mkinitrd and retest.  This doesn't contain the debug prints, so report back whether it works or not.
Comment 21 Antony J.R 2021-02-03 07:54:03 UTC
(In reply to Takashi Iwai from comment #20)
> Thanks.  Then I misunderstood situation as if the backlight control didn't
> take any effect.
> 

I mean the backlight is constantly at maximum brightness and I can't decrease or control it. The only thing works is the brightness slider in OpenSUSE and the brightness value is only reflected in /sys/class/backlight/amdgpu_bl0/brightness file but the backlight does not change at all. I think I misled you saying "Here the brightness changed when changed the brightness but actual_brightness is stuck at 311 constantly.", Here I said /sys/class/backlight/amdgpu_bl0/brightness changes when I change the brightness slider in the OS (or Fn Keys) but the backlight still remains at maximum brightness. 

> Now I refreshed the OBS KMP repo to contain the possible fix.  It's being
> rebuilt, and please give it a try later.  The rpm changelog should contain
> the entry like:
> - Add a proper fix (attempt):
>   0001-drm-amd-display-Fix-the-brightness-read-via-aux.patch
> 
> At first, uninstall the previous KMP, just do "zypper rm
> amdgpu-dbg-kmp-default"
> Then re-install the new rpm, run mkinitrd and retest.  This doesn't contain
> the debug prints, so report back whether it works or not.

I will report back ASAP.
Comment 22 Antony J.R 2021-02-03 08:29:25 UTC
It seems the package at the repo is not updated, I will try once it updates -> https://download.opensuse.org/repositories/home:/tiwai:/bsc1180749/standard/
Comment 23 Takashi Iwai 2021-02-03 09:02:09 UTC
It's because of a mistake in the previous packaging.  Now fixed and it's built, but the publishing seems taking long.

You can fetch the fresh package directly via osc command before publishing, too:
  osc getbinaries home:tiwai:bsc1180749/amdgpu-dbg/standard/x86_64
Comment 24 Antony J.R 2021-02-03 09:51:53 UTC
Okay, I've tested with your possible fix. But it did not work. Now /sys/class/backlight/actual_brightness reports valid values which is the same as /sys/class/backlight/brightness 

Now when I change the brightness both /sys/class/backlight/actual_brightness and /sys/class/backlight/brightness reports valid values but still the display brightness is at maximum and does not change.

Seems like this is not a easy fix.
Comment 25 Takashi Iwai 2021-02-03 10:09:31 UTC
OK, then you're hitting multiple issues, as it seems.

The inconsistent value read from sysfs was addressed by my patch.  But, I suppose that the main reason of the non-functional backlight is that the driver misdetected the backlight control over aux.

I refreshed again the KMP with a hack patch to disable the aux support.  Please give it a try later again.  This will show a line "XXX ext_caps=0x..." in kernel log.
Comment 26 Antony J.R 2021-02-03 11:43:40 UTC
(In reply to Takashi Iwai from comment #25)
> OK, then you're hitting multiple issues, as it seems.
> 
> The inconsistent value read from sysfs was addressed by my patch.  But, I
> suppose that the main reason of the non-functional backlight is that the
> driver misdetected the backlight control over aux.
> 
> I refreshed again the KMP with a hack patch to disable the aux support. 
> Please give it a try later again.  This will show a line "XXX
> ext_caps=0x..." in kernel log.

IT WORKED!!!!

Thank you for your time. I can now control the brightness with Fn Keys or the OS Slider in OpenSUSE. 

So the problem was with the aux detection. 

I know this is not a proper fix but it works. I hope you upstream this work to the mainline kernel or OpenSUSE patches??
Comment 27 Takashi Iwai 2021-02-03 12:28:09 UTC
OK, finally got some good news.

I'm rebuilding the KMP again with a patch to add a module option "aux_backlight" instead of blindly disabling the aux backlight.  So keep your working KMP for now, and check later the new KMP and test with
  amdgpu.aux_backlight=0
boot option.  This is no solution but an acceptable workaround, I suppose.

I'm going to submit two patches to upstream.

Oh, BTW, which value was shown in the "XXX ext_caps=..." line?
Comment 28 Takashi Iwai 2021-02-03 12:29:44 UTC
Created attachment 845785 [details]
Fix brightness sysfs value read for aux backlight
Comment 29 Takashi Iwai 2021-02-03 12:30:22 UTC
Created attachment 845786 [details]
Patch to add aux_backlight module option to amdgpu driver
Comment 30 Antony J.R 2021-02-03 12:39:57 UTC
(In reply to Takashi Iwai from comment #27)
> OK, finally got some good news.
> 
> I'm rebuilding the KMP again with a patch to add a module option
> "aux_backlight" instead of blindly disabling the aux backlight.  So keep
> your working KMP for now, and check later the new KMP and test with
>   amdgpu.aux_backlight=0
> boot option.  This is no solution but an acceptable workaround, I suppose.
> 
> I'm going to submit two patches to upstream.
> 

Yes it's okay but the official kernel maintainer and openSUSE is not going to accept this patch so I can see that the official support is very far away :P

> Oh, BTW, which value was shown in the "XXX ext_caps=..." line?

[    7.872674] amdgpu: XXX ext_caps=0xa7
Comment 31 Takashi Iwai 2021-03-05 09:31:40 UTC
Alex submitted the patches including my module parameter patch to the upstream amd-gfx ML, and now I updated amdgpu-dbg KMP based on those patches.  (And the debug print was dropped.)

Could you check it later together with the latest (matching) TW kernel?
Once after confirming it works for you, I'll merge those patches to TW kernel.

Even after merging TW, though, we'll still need to keep the upstream bug opened until more workarounds are implemented (e.g. DMI-based quirk entries).
Comment 32 Antony J.R 2021-03-06 12:40:37 UTC
(In reply to Takashi Iwai from comment #31)
> Alex submitted the patches including my module parameter patch to the
> upstream amd-gfx ML, and now I updated amdgpu-dbg KMP based on those
> patches.  (And the debug print was dropped.)
> 
> Could you check it later together with the latest (matching) TW kernel?
> Once after confirming it works for you, I'll merge those patches to TW
> kernel.
> 
> Even after merging TW, though, we'll still need to keep the upstream bug
> opened until more workarounds are implemented (e.g. DMI-based quirk entries).

Many thanks. With the kernel param amdgpu.backlight=0 the backlight brightness control works with the latest TW kernel and your package at the time of writing.

I wonder if we can get connected with any Lenovo or ASUS folks to find out what they did wrong? But I guess that's not gonna happen. Do they contribute anything open source in the first place?? Only time will tell :)
Comment 33 Takashi Iwai 2021-03-06 16:47:55 UTC
I backported the fixes to stable git branch for TW kernel now.

Unfortunately, we have no proper contact for both Lenovo and ASUS about the graphics.  Hopefully AMD people know anyone there...
Comment 36 Jeffrey Cheung 2021-03-16 02:06:21 UTC
(In reply to Takashi Iwai from comment #33)
> I backported the fixes to stable git branch for TW kernel now.
> 
> Unfortunately, we have no proper contact for both Lenovo and ASUS about the
> graphics.  Hopefully AMD people know anyone there...

I see the patches landed in kernel, should we close the bug report ?
Comment 37 Takashi Iwai 2021-03-16 07:43:14 UTC
Currently it allows user a control via a module option, but it's merely a manual workaround.  It needs the automatic correct setup, ideally speaking.
Comment 38 Jeffrey Cheung 2021-03-16 08:15:23 UTC
(In reply to Takashi Iwai from comment #37)
> Currently it allows user a control via a module option, but it's merely a
> manual workaround.  It needs the automatic correct setup, ideally speaking.

Of course, but I seems this is the best we can do at this moment.

Since you mention to keep the upstream bug open at comment#31, so I suggest to close this bug report and wait for upstream to fix / provide more workarounds.
Comment 39 Takashi Iwai 2021-03-16 08:18:57 UTC
If the forced disablement of the aux channel brightness is the only way, we can build up a quirk list based on DMI or such and let the driver automatically choose the right mode.  Such an implementation is trivial, but the primary question is what's the best way to detect that.  The quirk table is the last resort if no other generic probe doesn't work.
Comment 41 P 2021-05-31 17:01:43 UTC
Seizing the opportunity:

Is there a way to see if this fix is going to be part of the KOTD? I'm in the same boat as OP, and I love to make use of the fix :-)

As I'm on Leap 15.2 I could also raise a separate bug against Leap 15.2 if you guys would prefer this (maybe for tracking purposes).
Comment 42 Takashi Iwai 2021-05-31 17:09:51 UTC
The amdgpu.backlight module option was already merged in the upstream, so TW should have a workaround (passing amdgpu.backlight=0 boot option).  This was also already merged in SLE15-SP3 / Leap 15.3 kernel, too.  But I don't think we'd fix this for Leap 15.2.

The root cause of the problem hasn't been figured out yet.  My bet is that it's a BIOS bug, and more proper workarounds are needed in AMDGPU driver side, but this has to be sorted out in the upstream development.  Feel free to join to the upstream gitlab Issues.
Comment 45 Antony J.R 2021-10-31 03:48:29 UTC
(In reply to Takashi Iwai from comment #42)
> The amdgpu.backlight module option was already merged in the upstream, so TW
> should have a workaround (passing amdgpu.backlight=0 boot option).  This was
> also already merged in SLE15-SP3 / Leap 15.3 kernel, too.  But I don't think
> we'd fix this for Leap 15.2.
> 
> The root cause of the problem hasn't been figured out yet.  My bet is that
> it's a BIOS bug, and more proper workarounds are needed in AMDGPU driver
> side, but this has to be sorted out in the upstream development.  Feel free
> to join to the upstream gitlab Issues.

It seems that without the amdgpu.backlight=0 kernel parameter the brightness control is working in hybrid mode. I don't know what fixed it maybe this https://gitlab.freedesktop.org/agd5f/linux/-/commit/f2ad3accefc63e72e9932e141c21875cc04beec8 commit.

But the brightness control seems to work good now in Linux 5.14.14 in TW.
Comment 46 Takashi Iwai 2021-11-03 16:27:13 UTC
Thanks for the updates.  The commit mentioned above is also included in SLE15-SP3 kernel, so hopefully everything works now.  Let's close for now.
Comment 49 Swamp Workflow Management 2021-11-16 20:20:29 UTC
SUSE-SU-2021:3675-1: An update that solves 15 vulnerabilities and has 56 fixes is now available.

Category: security (important)
Bug References: 1065729,1085030,1089118,1094840,1133021,1152472,1152489,1154353,1156395,1157177,1167773,1172073,1173604,1176447,1176774,1176914,1176940,1178134,1180100,1180749,1181147,1184673,1185762,1186063,1186109,1187167,1188563,1188601,1189841,1190006,1190067,1190349,1190351,1190479,1190620,1190642,1190795,1190801,1190941,1191229,1191240,1191241,1191315,1191317,1191349,1191384,1191449,1191450,1191451,1191452,1191455,1191456,1191628,1191645,1191663,1191731,1191800,1191851,1191867,1191934,1191958,1191980,1192040,1192041,1192074,1192107,1192145,1192229,1192267,1192288,1192549
CVE References: CVE-2021-33033,CVE-2021-34866,CVE-2021-3542,CVE-2021-3655,CVE-2021-3715,CVE-2021-37159,CVE-2021-3760,CVE-2021-3772,CVE-2021-3896,CVE-2021-41864,CVE-2021-42008,CVE-2021-42252,CVE-2021-42739,CVE-2021-43056,CVE-2021-43389
JIRA References: 
Sources used:
SUSE MicroOS 5.1 (src):    kernel-default-5.3.18-59.34.1, kernel-default-base-5.3.18-59.34.1.18.21.1
SUSE Linux Enterprise Workstation Extension 15-SP3 (src):    kernel-default-5.3.18-59.34.1, kernel-preempt-5.3.18-59.34.1
SUSE Linux Enterprise Module for Live Patching 15-SP3 (src):    kernel-default-5.3.18-59.34.1, kernel-livepatch-SLE15-SP3_Update_9-1-7.3.1
SUSE Linux Enterprise Module for Legacy Software 15-SP3 (src):    kernel-default-5.3.18-59.34.1
SUSE Linux Enterprise Module for Development Tools 15-SP3 (src):    kernel-docs-5.3.18-59.34.1, kernel-obs-build-5.3.18-59.34.1, kernel-preempt-5.3.18-59.34.1, kernel-source-5.3.18-59.34.1, kernel-syms-5.3.18-59.34.1
SUSE Linux Enterprise Module for Basesystem 15-SP3 (src):    kernel-64kb-5.3.18-59.34.1, kernel-default-5.3.18-59.34.1, kernel-default-base-5.3.18-59.34.1.18.21.1, kernel-preempt-5.3.18-59.34.1, kernel-source-5.3.18-59.34.1, kernel-zfcpdump-5.3.18-59.34.1
SUSE Linux Enterprise High Availability 15-SP3 (src):    kernel-default-5.3.18-59.34.1

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.
Comment 50 Swamp Workflow Management 2021-11-16 20:31:00 UTC
openSUSE-SU-2021:3675-1: An update that solves 15 vulnerabilities and has 56 fixes is now available.

Category: security (important)
Bug References: 1065729,1085030,1089118,1094840,1133021,1152472,1152489,1154353,1156395,1157177,1167773,1172073,1173604,1176447,1176774,1176914,1176940,1178134,1180100,1180749,1181147,1184673,1185762,1186063,1186109,1187167,1188563,1188601,1189841,1190006,1190067,1190349,1190351,1190479,1190620,1190642,1190795,1190801,1190941,1191229,1191240,1191241,1191315,1191317,1191349,1191384,1191449,1191450,1191451,1191452,1191455,1191456,1191628,1191645,1191663,1191731,1191800,1191851,1191867,1191934,1191958,1191980,1192040,1192041,1192074,1192107,1192145,1192229,1192267,1192288,1192549
CVE References: CVE-2021-33033,CVE-2021-34866,CVE-2021-3542,CVE-2021-3655,CVE-2021-3715,CVE-2021-37159,CVE-2021-3760,CVE-2021-3772,CVE-2021-3896,CVE-2021-41864,CVE-2021-42008,CVE-2021-42252,CVE-2021-42739,CVE-2021-43056,CVE-2021-43389
JIRA References: 
Sources used:
openSUSE Leap 15.3 (src):    dtb-aarch64-5.3.18-59.34.1, kernel-64kb-5.3.18-59.34.1, kernel-debug-5.3.18-59.34.1, kernel-default-5.3.18-59.34.1, kernel-default-base-5.3.18-59.34.1.18.21.1, kernel-docs-5.3.18-59.34.1, kernel-kvmsmall-5.3.18-59.34.1, kernel-obs-build-5.3.18-59.34.1, kernel-obs-qa-5.3.18-59.34.1, kernel-preempt-5.3.18-59.34.1, kernel-source-5.3.18-59.34.1, kernel-syms-5.3.18-59.34.1, kernel-zfcpdump-5.3.18-59.34.1
Comment 52 Swamp Workflow Management 2021-11-25 17:18:54 UTC
SUSE-SU-2021:3806-1: An update that solves 6 vulnerabilities, contains one feature and has 35 fixes is now available.

Category: security (important)
Bug References: 1094840,1133021,1152489,1154353,1157177,1167773,1169263,1170269,1176940,1180749,1184924,1188601,1190523,1190795,1191628,1191790,1191851,1191958,1191961,1191980,1192045,1192217,1192229,1192267,1192273,1192288,1192328,1192375,1192473,1192549,1192718,1192740,1192745,1192750,1192753,1192758,1192781,1192802,1192896,1192906,1192918
CVE References: CVE-2021-0941,CVE-2021-20322,CVE-2021-31916,CVE-2021-34981,CVE-2021-37159,CVE-2021-43389
JIRA References: SLE-22573
Sources used:
SUSE Linux Enterprise Module for Public Cloud 15-SP3 (src):    kernel-azure-5.3.18-38.31.1, kernel-source-azure-5.3.18-38.31.1, kernel-syms-azure-5.3.18-38.31.1

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.
Comment 53 Swamp Workflow Management 2021-11-25 17:28:19 UTC
openSUSE-SU-2021:3806-1: An update that solves 6 vulnerabilities, contains one feature and has 35 fixes is now available.

Category: security (important)
Bug References: 1094840,1133021,1152489,1154353,1157177,1167773,1169263,1170269,1176940,1180749,1184924,1188601,1190523,1190795,1191628,1191790,1191851,1191958,1191961,1191980,1192045,1192217,1192229,1192267,1192273,1192288,1192328,1192375,1192473,1192549,1192718,1192740,1192745,1192750,1192753,1192758,1192781,1192802,1192896,1192906,1192918
CVE References: CVE-2021-0941,CVE-2021-20322,CVE-2021-31916,CVE-2021-34981,CVE-2021-37159,CVE-2021-43389
JIRA References: SLE-22573
Sources used:
openSUSE Leap 15.3 (src):    kernel-azure-5.3.18-38.31.1, kernel-source-azure-5.3.18-38.31.1, kernel-syms-azure-5.3.18-38.31.1