Bug 1183872 - System hang when connecting HMDI on i915 with CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM=y
System hang when connecting HMDI on i915 with CONFIG_SND_HDA_INTEL_HDMI_SILEN...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
x86-64 openSUSE Tumbleweed
: P5 - None : Normal (vote)
: ---
Assigned To: Takashi Iwai
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-03-22 19:33 UTC by Imnotgivingmy nametoamachine
Modified: 2022-08-01 13:25 UTC (History)
4 users (show)

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


Attachments
Hardware info (1.97 KB, text/plain)
2021-03-22 19:33 UTC, Imnotgivingmy nametoamachine
Details
dmesg with call trace referencing i915 after connecting a screen by HDMI (62.83 KB, text/plain)
2021-03-26 16:27 UTC, Imnotgivingmy nametoamachine
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Imnotgivingmy nametoamachine 2021-03-22 19:33:08 UTC
Created attachment 847526 [details]
Hardware info

This bug doesn't occur on Leap 15.2 but it happens very consistently on Tumbleweed.

How to reproduce:
1) Connect an external screen by HDMI *after* turning on the computer

Expected behavior:
The screen is recognized

Actual behavior:
Both screen go blank and the system is unusable

If the screen is connected before turning on the computer then it will work as expected, but if it's re-plugged it will still hang.

This isn't a desktop environment specific issue and it happens even without any X server at all.

Speculation:
This is most likely a kernel issue, specifically a bug in the i915 driver. If so, it was introduced between Linux 5.3 and 5.11.

Things that were tried:
i915.enable_psr=0 still, intel_idle.max_cstate=1 and i915.enable_dc=0 where all tried but the bug still occur.
Tried to get a dump with kdump but nothing was written in /var/crash.

Any tips to debug this issue so it can be narrowed down would be really helpful. I'm currently trying to find a way to test every kernel from 5.3 to 5.11 without having to actually compile them on tumbleweed, so it can, without a doubt confirmed it's a kernel issue and also find the version on which the regression was introduced.
Comment 1 Takashi Iwai 2021-03-23 12:54:16 UTC
Could you check the older kernels in TW history repo and see whether the problem is seen there?
  http://download.opensuse.org/history/

Some even older kernels are found in my OBS kernel repos, e.g. OBS home:tiwai:kernel:5.9, home:tiwai:kernel:5.8, ..., too:
  http://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.9/standard/
Comment 2 Takashi Iwai 2021-03-23 12:59:33 UTC
For the kdump: might it help to set panic_on_oops sysctl?

And, make sure that kdump really works as expected beforehand, e.g. triggering via "echo -c > /proc/sysrq-trigger".

Last but not least, if you find some more information, please report it to the upstream, gitlab.freedesktop.org Issues.  Thanks.
Comment 3 Imnotgivingmy nametoamachine 2021-03-23 18:57:00 UTC
Thank you very much for maintaining your repository with all those previous versions.
I found this regression was introduced between Linux 5.8.15-1.1.gc680e93 and 5.9.14-1.1.gc648a46
Then tested with 5.12.rc4-1.1.g094141b just to make sure it's still present.
I'll report this to upstream then in https://gitlab.freedesktop.org/drm/intel now that i'm 100% sure that this is a kernel bug.
Comment 4 Felix Miata 2021-03-24 04:33:23 UTC
FWIW I think this is a laptop-only issue. I just booted TW20210320 on Kaby Lake graphics while connected to display via DisplayPort. After boot completion I plugged in an HDMI cable to a second display, and both are working as expected producing 2560x2520 desktop via modesetting DDX.

Is the external display connected only to the laptop's HDMI, or is some other cable simultaneously connected to some other device's output even though not powered up?
Comment 5 Takashi Iwai 2021-03-26 09:18:42 UTC
Surely this must be machine or some platform-specific, otherwise lots of people would have already complained :)

Please give the gitlab issues URL if you've already reported so that we can track there, too.

And, any attemp to kdump wasn't successful?
Comment 6 Imnotgivingmy nametoamachine 2021-03-26 16:27:47 UTC
Created attachment 847713 [details]
dmesg with call trace referencing i915 after connecting a screen by HDMI

>FWIW I think this is a laptop-only issue.
Or a GeminiLake-only issue. But yes it doesn't seem to affect every device using i915.

Is the external display connected only to the laptop's HDMI?
Yes, that's the only external screen connected to the only HDMI port on that laptop. There's also the internal screen of course.

>or is some other cable simultaneously connected to some other device's output even though not powered up?
No

>Please give the gitlab issues URL
https://gitlab.freedesktop.org/drm/intel/-/issues/3285

>And, any attemp to kdump wasn't successful?
Nope, I didn't had any luck with kdump, ended up disabling it since I never got any logs but still consumed the 210MB of memory. On the bright side just a few hours ago I finally got a dmesg log with a call trace that reference i915 in it.
It can be found on the link but I'll attach it here for completeness.
Comment 7 Takashi Iwai 2021-03-28 08:06:19 UTC
(In reply to Imnotgivingmy nametoamachine from comment #6)
> Created attachment 847713 [details]
> dmesg with call trace referencing i915 after connecting a screen by HDMI

The kernel stack trace shown there is from the wireless stack, so it's not directly something to do with i915 stuff.

Are you enabling netconsole?  It might be the reason.
Comment 8 Imnotgivingmy nametoamachine 2021-03-28 16:12:34 UTC
(In reply to Takashi Iwai from comment #7)
> (In reply to Imnotgivingmy nametoamachine from comment #6)
> > Created attachment 847713 [details]
> > dmesg with call trace referencing i915 after connecting a screen by HDMI
> 
> The kernel stack trace shown there is from the wireless stack, so it's not
> directly something to do with i915 stuff.
> 
> Are you enabling netconsole?  It might be the reason.

Yes, I was told to use netconsole to capture the dmesg log as I reproduced the bug. Dang I was hoping this log would be it.
Comment 9 Imnotgivingmy nametoamachine 2021-03-29 01:22:34 UTC
I'm very confused about the nature of this bug and if it's really a bug in the kernel and not some other component as I have tried with Arch and Ubuntu and I was able to reproduce this bug on Arch with their install media iso that doesn't have xorg, and so far that seemed normal. But I also tested this bug on the same hardware with ubuntu 18.04, 20.04, 20.10 and 21.04 all with the kernels they come with and also with https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.12-rc4/
As far as I know mainline doesn't have ubuntu's patches so it should be "vanilla". But I have this bug on opensuse with 5.12-rc4-vanilla (and arch) and not on ubuntu with 5.12-rc4-mainline.


Takashi Iwai, is it possible for you to do an updated vanilla build of drm-tip
as you have in http://download.opensuse.org/repositories/home:/tiwai:/kernel:/drm-tip/standard/
but updated to include commits from the last two weeks? I'm very confused by not being able to reproduce this bug on ubuntu and testing with drm-tip on opensuse is one of the few things I haven't tried.
Comment 10 Takashi Iwai 2021-03-29 07:42:22 UTC
It's being rebuilt now.  I didn't notice that the automatic update stopped working...
Comment 11 Imnotgivingmy nametoamachine 2021-03-29 17:41:34 UTC
(In reply to Takashi Iwai from comment #10)
> It's being rebuilt now.  I didn't notice that the automatic update stopped
> working...

Thank you very much Takashi! I tested with (drm-tip) kernel-vanilla-5.12.rc4-2.1.ga3c6ee1 but sadly the bug was still present.

I then went ahead and tested with kernel-vanilla-5.12.rc5-1.1.g5fe2d5c because I notice it was available too, you know just to make sure the bug was indeed still present and all... But the bug doesn't happen with 5.12.rc5-vanilla...

Just what the fuck? Was the bug really fixed in exactly the week I reported the bug but without finding an useful log or call trace? And why the bug didn't happened on ubuntu? To be honest despite the bug looking like it's fixed on 5.12.rc5 it's now more annoying not knowing why or how it was fixed haha

I'm legit going to read all the commits between 5.12.rc4 and 5.12.rc5

That aside what should the status of this bug be? Is it "Resolved" as soon as there is a patch coming up in a future stable version or it's Resolved until that patch finally reaches a stable kernel in opensuse?
Comment 12 Takashi Iwai 2021-03-30 12:36:57 UTC
(In reply to Imnotgivingmy nametoamachine from comment #11)
> (In reply to Takashi Iwai from comment #10)
> > It's being rebuilt now.  I didn't notice that the automatic update stopped
> > working...
> 
> Thank you very much Takashi! I tested with (drm-tip)
> kernel-vanilla-5.12.rc4-2.1.ga3c6ee1 but sadly the bug was still present.
> 
> I then went ahead and tested with kernel-vanilla-5.12.rc5-1.1.g5fe2d5c
> because I notice it was available too, you know just to make sure the bug
> was indeed still present and all... But the bug doesn't happen with
> 5.12.rc5-vanilla...
> 
> Just what the fuck? Was the bug really fixed in exactly the week I reported
> the bug but without finding an useful log or call trace? And why the bug
> didn't happened on ubuntu? To be honest despite the bug looking like it's
> fixed on 5.12.rc5 it's now more annoying not knowing why or how it was fixed
> haha
> 
> I'm legit going to read all the commits between 5.12.rc4 and 5.12.rc5
> 
> That aside what should the status of this bug be? Is it "Resolved" as soon
> as there is a patch coming up in a future stable version or it's Resolved
> until that patch finally reaches a stable kernel in opensuse?

You need to really make sure that it's fixed in 5.12-rc5 code itself.
For example, 5.12-rc5 kernel you've tested also contains the kernel configuration change to make CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM=n.
This might be the cause, too.

And, if that's the case, you could work around in other kernels by passing
  snd_hda_codec_hdmi.enable_silent_stream=0
boot option, too.
Comment 13 Imnotgivingmy nametoamachine 2021-03-30 16:54:26 UTC
(In reply to Takashi Iwai from comment #12)
> (In reply to Imnotgivingmy nametoamachine from comment #11)
> > (In reply to Takashi Iwai from comment #10)
> > > It's being rebuilt now.  I didn't notice that the automatic update stopped
> > > working...
> > 
> > Thank you very much Takashi! I tested with (drm-tip)
> > kernel-vanilla-5.12.rc4-2.1.ga3c6ee1 but sadly the bug was still present.
> > 
> > I then went ahead and tested with kernel-vanilla-5.12.rc5-1.1.g5fe2d5c
> > because I notice it was available too, you know just to make sure the bug
> > was indeed still present and all... But the bug doesn't happen with
> > 5.12.rc5-vanilla...
> > 
> > Just what the fuck? Was the bug really fixed in exactly the week I reported
> > the bug but without finding an useful log or call trace? And why the bug
> > didn't happened on ubuntu? To be honest despite the bug looking like it's
> > fixed on 5.12.rc5 it's now more annoying not knowing why or how it was fixed
> > haha
> > 
> > I'm legit going to read all the commits between 5.12.rc4 and 5.12.rc5
> > 
> > That aside what should the status of this bug be? Is it "Resolved" as soon
> > as there is a patch coming up in a future stable version or it's Resolved
> > until that patch finally reaches a stable kernel in opensuse?
> 
> You need to really make sure that it's fixed in 5.12-rc5 code itself.
> For example, 5.12-rc5 kernel you've tested also contains the kernel
> configuration change to make CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM=n.
> This might be the cause, too.
> 
> And, if that's the case, you could work around in other kernels by passing
>   snd_hda_codec_hdmi.enable_silent_stream=0
> boot option, too.

This might be the issue

(affected by this bug) config-5.11.6-1-vanilla:
>CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM=y

(affected by this bug) config-5.12.0-rc4-2.ga3c6ee1-vanilla:
>CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM=y

(drm-tip, affected by this bug) config-5.12.0-rc4-3.ge9c25f7-vanilla:
>CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM=y

All kernels build by ubuntu (none affected):
># CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM is not set

(not affected) config-5.12.0-rc5-1.g5fe2d5c-vanilla:
># CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM is not set

5.12.0-rc4-2.ga3c6ee1-vanilla booted with snd_hda_codec_hdmi.enable_silent_stream=0 results in the gpu freeze to never happen

Also from https://cateee.net/lkddb/web-lkddb/SND_HDA_INTEL_HDMI_SILENT_STREAM.html
>found in Linux kernels: 5.9–5.11, 5.12-rc+HEAD
5.9 was the first kernel I had issues when testing with the kernels in your repo.

Looks like silent_stream is indeed the issue, how did you find it?
Comment 14 Takashi Iwai 2021-03-30 17:01:20 UTC
Heh, it was a blind shot.

OK, then the next problem is why this causes a problem.

Does your hardware have only Intel graphics chip, and no discrete GPU for rendering, right?  Just to be sure which driver is involved in this game.
Comment 15 Imnotgivingmy nametoamachine 2021-03-30 17:16:48 UTC
(In reply to Takashi Iwai from comment #14)
> Heh, it was a blind shot.
> 
> OK, then the next problem is why this causes a problem.
> 
> Does your hardware have only Intel graphics chip, and no discrete GPU for
> rendering, right?  Just to be sure which driver is involved in this game.

Exactly so, only Intel graphics UHD Graphics 600 and no discrete GPU. I'm not sure how the hdmi port is wired inside the laptop, as in if it goes directly to the GPU or goes through some other controller. A motherboard schematic might be useful maybe?
Comment 16 Takashi Iwai 2021-03-31 07:45:33 UTC
OK, then I need to ping Intel audio people.

Since the issue is with the HDMI audio: can you play via HDMI audio at all?
At least no hang happens?
Comment 17 Imnotgivingmy nametoamachine 2021-03-31 17:50:10 UTC
(In reply to Takashi Iwai from comment #16)
> OK, then I need to ping Intel audio people.
> 
> Since the issue is with the HDMI audio: can you play via HDMI audio at all?
> At least no hang happens?

Yes, I can play audio over HDMI on the TV just fine with Linux 5.8 or previous, or Linux 5.9 and later with CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM disabled.

Should I close the issue on DRM Intel?
Comment 18 Imnotgivingmy nametoamachine 2021-03-31 18:29:43 UTC
(In reply to Imnotgivingmy nametoamachine from comment #17)
> (In reply to Takashi Iwai from comment #16)
> > OK, then I need to ping Intel audio people.
> > 
> > Since the issue is with the HDMI audio: can you play via HDMI audio at all?
> > At least no hang happens?
> 
> Yes, I can play audio over HDMI on the TV just fine with Linux 5.8 or
> previous, or Linux 5.9 and later with
> CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM disabled.
> 
> Should I close the issue on DRM Intel?

Oh, another detail that might be useful. Even with CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM enabled this bug doesn't happen if the screen is connected *before* turning on the computer, and HDMI audio works too. But it isn't reliable as reconnecting the external screen, or changing the resolution, or even so much as changing the screen mode (changing to mirror for example) will then trigger this bug crashing the system.
Comment 19 Kai Vehmanen 2021-03-31 19:30:14 UTC
Kai from Intel audio team joining the thread. Thanks for the bug report and providing lot of details on the case.

We'll try to reproduce this bug on some GeminiLake system.

If that fails, we might need some further details. This is probably happening in linux/sound/pci/hda/patch_hdmi.c:sync_eld_via_acomp(). Commenting out "silent_stream_enable()" and "silent_stream_disable()" calls in that function would be interesting experiment on a setup that triggers this. It could be the snd_hda_power_up_pm() call, but that would seem unlikely, so most probably something goes wrong in silent_stream_enable().
Comment 20 Imnotgivingmy nametoamachine 2021-04-01 04:50:39 UTC
(In reply to Kai Vehmanen from comment #19)
> This is probably happening in linux/sound/pci/hda/patch_hdmi.c:sync_eld_via_acomp().
> Commenting out "silent_stream_enable()" and "silent_stream_disable()" calls
> in that function would be interesting experiment on a setup that triggers
> this. It could be the snd_hda_power_up_pm() call, but that would seem
> unlikely, so most probably something goes wrong in silent_stream_enable().

Say no more! One kernel compilation that might yield some concrete results I can bare (since I'm currently with very weak hardware and compiling the kernel takes over an hour at best, and not a few minutes or even seconds like probably does in your development machines)
I'll do it tomorrow since it's late here, or if Takashi can spoil me a bit more with a patched kernel from OBS that would be awesome *wink* *wink*

Also speaking of OBS is it open to everyone or just for suse developers? I can probably learn to use it and patch test kernels myself, (if I can use it) so I don't waste Takashi's time with boring, one time kernel builds for testing.
Comment 21 Takashi Iwai 2021-04-01 07:52:18 UTC
Don't worry about the kernel build; it's an easy task for me if a proper patch is provided.  After all, it's about the code I've been maintaining in the upstream, so I'd have to be involved in anyway :)

About OBS: yes, every one can use it and can build the stuff as they want.
It's only that the (open)SUSE kernel build is a bit tricky in comparison with other packages.
Comment 22 Kai Vehmanen 2021-04-15 09:53:00 UTC
Status update: I've asked our test team to try and reproduce but so far with no luck. I do wonder if this could be related to one other currently on my table:
https://github.com/thesofproject/linux/issues/2825 "HDMI monitor plug during S3 suspend is lost ".

In that bug, we have a race between codec driver PM transitions and the monitor/ELD hotplug notification. When silent stream is on, we do a PM request right from the ELD nofity cb. The code looks safe, but this could be related.
Comment 23 Takashi Iwai 2021-04-17 08:17:00 UTC
OK, then I'm building a test kernel with the backport of your recent upstream fix ("ALSA: hda/hdmi: fix race in handling acomp ELD notification at resume").
The test kernel is being built in OBS home:tiwai:bsc1183872 repo.  It'll be available (after an hour or so) at
  http://download.opensuse.org/repositories/home:/tiwai:/bsc1183872/standard/

Please give it a try later.
Comment 24 Imnotgivingmy nametoamachine 2021-05-07 03:48:34 UTC
(In reply to Takashi Iwai from comment #23)
> OK, then I'm building a test kernel with the backport of your recent
> upstream fix ("ALSA: hda/hdmi: fix race in handling acomp ELD notification
> at resume").
> The test kernel is being built in OBS home:tiwai:bsc1183872 repo.  It'll be
> available (after an hour or so) at
>   http://download.opensuse.org/repositories/home:/tiwai:/bsc1183872/standard/
> 
> Please give it a try later.

Sorry for going inactive for so long, my car broke (compression leak on two cylinders) and the whole situation of not having a car while also trying to diagnose and then fix the issue took my whole free time for weeks. But my car issue it's almost solved now and I finally have some free time again.
I'll try this tomorrow, thanks for not closing it due to inactivity.
Comment 25 Imnotgivingmy nametoamachine 2022-02-04 01:17:21 UTC
Hello, I wanted to get back into this. updated everything and now with Linux 5.16.2-1 I'm unable to reproduce this bug, I don't have snd_hda_codec_hdmi.enable_silent_stream in my boot options nor I can see anything resembling that option in sysctl -a
So, I'm closing this as someone else probably reported it and got it fixed.
Comment 26 Kai Vehmanen 2022-02-08 12:16:04 UTC
(In reply to Imnotgivingmy nametoamachine from comment #25)
> Hello, I wanted to get back into this. updated everything and now with Linux
> 5.16.2-1 I'm unable to reproduce this bug, I don't have
> snd_hda_codec_hdmi.enable_silent_stream in my boot options nor I can see
> anything resembling that option in sysctl -a
> So, I'm closing this as someone else probably reported it and got it fixed.

Thank you for updating on the bug. There was one issue found and fixed specifically for Gemini Lake and this was probably the rootcause for your problem as well. Tracked in https://gitlab.freedesktop.org/drm/intel/-/issues/2623#note_1249445
Comment 27 Takashi Iwai 2022-02-08 14:55:06 UTC
Yes, the upstream fix commit is b6fd77472dea76b7a2bad3a338ade920152972b8, and that's been already backported, too.

I'll update the patch reference tag accordingly, too.
Comment 35 Swamp Workflow Management 2022-03-08 23:18:17 UTC
openSUSE-SU-2022:0760-1: An update that solves 6 vulnerabilities, contains three features and has 50 fixes is now available.

Category: security (important)
Bug References: 1089644,1154353,1157038,1157923,1176447,1176940,1178134,1181147,1181588,1183872,1187716,1188404,1189126,1190812,1190972,1191580,1191655,1191741,1192210,1192483,1193096,1193233,1193243,1193787,1194163,1194967,1195012,1195081,1195286,1195352,1195378,1195506,1195516,1195543,1195668,1195701,1195798,1195799,1195823,1195908,1195928,1195947,1195957,1195995,1196195,1196235,1196339,1196373,1196400,1196403,1196516,1196584,1196585,1196601,1196612,1196776
CVE References: CVE-2022-0001,CVE-2022-0002,CVE-2022-0492,CVE-2022-0516,CVE-2022-0847,CVE-2022-25375
JIRA References: SLE-20807,SLE-22135,SLE-22494
Sources used:
openSUSE Leap 15.4 (src):    dtb-aarch64-5.3.18-150300.59.54.1, kernel-preempt-5.3.18-150300.59.54.1
openSUSE Leap 15.3 (src):    dtb-aarch64-5.3.18-150300.59.54.1, kernel-64kb-5.3.18-150300.59.54.1, kernel-debug-5.3.18-150300.59.54.1, kernel-default-5.3.18-150300.59.54.1, kernel-default-base-5.3.18-150300.59.54.1.150300.18.35.3, kernel-docs-5.3.18-150300.59.54.1, kernel-kvmsmall-5.3.18-150300.59.54.1, kernel-obs-build-5.3.18-150300.59.54.1, kernel-obs-qa-5.3.18-150300.59.54.1, kernel-preempt-5.3.18-150300.59.54.1, kernel-source-5.3.18-150300.59.54.1, kernel-syms-5.3.18-150300.59.54.1, kernel-zfcpdump-5.3.18-150300.59.54.1
Comment 36 Swamp Workflow Management 2022-03-08 23:26:27 UTC
SUSE-SU-2022:0763-1: An update that solves three vulnerabilities, contains three features and has 43 fixes is now available.

Category: security (important)
Bug References: 1089644,1154353,1157038,1157923,1176447,1176940,1178134,1181147,1181588,1183872,1187716,1188404,1189126,1190812,1190972,1191580,1191655,1191741,1192210,1192483,1193096,1193233,1193243,1193787,1194163,1194967,1195012,1195081,1195286,1195352,1195378,1195506,1195668,1195701,1195798,1195799,1195823,1195928,1195957,1195995,1196195,1196235,1196339,1196400,1196516,1196584
CVE References: CVE-2022-0001,CVE-2022-0002,CVE-2022-25375
JIRA References: SLE-20807,SLE-22135,SLE-22494
Sources used:
SUSE Linux Enterprise Module for Realtime 15-SP3 (src):    kernel-rt-5.3.18-150300.79.1, kernel-rt_debug-5.3.18-150300.79.1, kernel-source-rt-5.3.18-150300.79.1, kernel-syms-rt-5.3.18-150300.79.1
SUSE Linux Enterprise Micro 5.1 (src):    kernel-rt-5.3.18-150300.79.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 37 Swamp Workflow Management 2022-03-08 23:34:33 UTC
SUSE-SU-2022:0755-1: An update that solves 6 vulnerabilities, contains three features and has 56 fixes is now available.

Category: security (important)
Bug References: 1089644,1154353,1156395,1157038,1157923,1176447,1176940,1178134,1181147,1181588,1183872,1187716,1188404,1189126,1190812,1190972,1191580,1191655,1191741,1192210,1192483,1193096,1193233,1193243,1193787,1194163,1194967,1195012,1195081,1195142,1195352,1195378,1195476,1195477,1195478,1195479,1195480,1195481,1195482,1195506,1195516,1195543,1195668,1195701,1195798,1195799,1195823,1195908,1195928,1195947,1195957,1195995,1196195,1196235,1196339,1196400,1196403,1196516,1196584,1196601,1196612,1196776
CVE References: CVE-2022-0001,CVE-2022-0002,CVE-2022-0492,CVE-2022-0516,CVE-2022-0847,CVE-2022-25375
JIRA References: SLE-20807,SLE-22135,SLE-22494
Sources used:
SUSE Linux Enterprise Module for Public Cloud 15-SP3 (src):    kernel-azure-5.3.18-150300.38.47.1, kernel-source-azure-5.3.18-150300.38.47.1, kernel-syms-azure-5.3.18-150300.38.47.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 38 Swamp Workflow Management 2022-03-08 23:42:31 UTC
openSUSE-SU-2022:0755-1: An update that solves 6 vulnerabilities, contains three features and has 56 fixes is now available.

Category: security (important)
Bug References: 1089644,1154353,1156395,1157038,1157923,1176447,1176940,1178134,1181147,1181588,1183872,1187716,1188404,1189126,1190812,1190972,1191580,1191655,1191741,1192210,1192483,1193096,1193233,1193243,1193787,1194163,1194967,1195012,1195081,1195142,1195352,1195378,1195476,1195477,1195478,1195479,1195480,1195481,1195482,1195506,1195516,1195543,1195668,1195701,1195798,1195799,1195823,1195908,1195928,1195947,1195957,1195995,1196195,1196235,1196339,1196400,1196403,1196516,1196584,1196601,1196612,1196776
CVE References: CVE-2022-0001,CVE-2022-0002,CVE-2022-0492,CVE-2022-0516,CVE-2022-0847,CVE-2022-25375
JIRA References: SLE-20807,SLE-22135,SLE-22494
Sources used:
openSUSE Leap 15.3 (src):    kernel-azure-5.3.18-150300.38.47.1, kernel-source-azure-5.3.18-150300.38.47.1, kernel-syms-azure-5.3.18-150300.38.47.1
Comment 39 Swamp Workflow Management 2022-03-08 23:54:39 UTC
SUSE-SU-2022:0760-1: An update that solves 6 vulnerabilities, contains three features and has 50 fixes is now available.

Category: security (important)
Bug References: 1089644,1154353,1157038,1157923,1176447,1176940,1178134,1181147,1181588,1183872,1187716,1188404,1189126,1190812,1190972,1191580,1191655,1191741,1192210,1192483,1193096,1193233,1193243,1193787,1194163,1194967,1195012,1195081,1195286,1195352,1195378,1195506,1195516,1195543,1195668,1195701,1195798,1195799,1195823,1195908,1195928,1195947,1195957,1195995,1196195,1196235,1196339,1196373,1196400,1196403,1196516,1196584,1196585,1196601,1196612,1196776
CVE References: CVE-2022-0001,CVE-2022-0002,CVE-2022-0492,CVE-2022-0516,CVE-2022-0847,CVE-2022-25375
JIRA References: SLE-20807,SLE-22135,SLE-22494
Sources used:
SUSE Linux Enterprise Workstation Extension 15-SP3 (src):    kernel-default-5.3.18-150300.59.54.1, kernel-preempt-5.3.18-150300.59.54.1
SUSE Linux Enterprise Module for Live Patching 15-SP3 (src):    kernel-default-5.3.18-150300.59.54.1, kernel-livepatch-SLE15-SP3_Update_15-1-150300.7.5.1
SUSE Linux Enterprise Module for Legacy Software 15-SP3 (src):    kernel-default-5.3.18-150300.59.54.1
SUSE Linux Enterprise Module for Development Tools 15-SP3 (src):    kernel-docs-5.3.18-150300.59.54.1, kernel-obs-build-5.3.18-150300.59.54.1, kernel-preempt-5.3.18-150300.59.54.1, kernel-source-5.3.18-150300.59.54.1, kernel-syms-5.3.18-150300.59.54.1
SUSE Linux Enterprise Module for Basesystem 15-SP3 (src):    kernel-64kb-5.3.18-150300.59.54.1, kernel-default-5.3.18-150300.59.54.1, kernel-default-base-5.3.18-150300.59.54.1.150300.18.35.3, kernel-preempt-5.3.18-150300.59.54.1, kernel-source-5.3.18-150300.59.54.1, kernel-zfcpdump-5.3.18-150300.59.54.1
SUSE Linux Enterprise Micro 5.1 (src):    kernel-default-5.3.18-150300.59.54.1, kernel-default-base-5.3.18-150300.59.54.1.150300.18.35.3
SUSE Linux Enterprise High Availability 15-SP3 (src):    kernel-default-5.3.18-150300.59.54.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 52 Swamp Workflow Management 2022-07-21 22:23:18 UTC
SUSE-SU-2022:2520-1: An update that solves 49 vulnerabilities, contains 26 features and has 207 fixes is now available.

Category: security (important)
Bug References: 1055117,1061840,1065729,1071995,1089644,1103269,1118212,1121726,1137728,1156395,1157038,1157923,1175667,1179439,1179639,1180814,1183682,1183872,1184318,1184924,1187716,1188885,1189998,1190137,1190208,1190336,1190497,1190768,1190786,1190812,1191271,1191663,1192483,1193064,1193277,1193289,1193431,1193556,1193629,1193640,1193787,1193823,1193852,1194086,1194111,1194191,1194409,1194501,1194523,1194526,1194583,1194585,1194586,1194625,1194765,1194826,1194869,1195099,1195287,1195478,1195482,1195504,1195651,1195668,1195669,1195775,1195823,1195826,1195913,1195915,1195926,1195944,1195957,1195987,1196079,1196114,1196130,1196213,1196306,1196367,1196400,1196426,1196478,1196514,1196570,1196723,1196779,1196830,1196836,1196866,1196868,1196869,1196901,1196930,1196942,1196960,1197016,1197157,1197227,1197243,1197292,1197302,1197303,1197304,1197362,1197386,1197501,1197601,1197661,1197675,1197761,1197817,1197819,1197820,1197888,1197889,1197894,1197915,1197917,1197918,1197920,1197921,1197922,1197926,1198009,1198010,1198012,1198013,1198014,1198015,1198016,1198017,1198018,1198019,1198020,1198021,1198022,1198023,1198024,1198027,1198030,1198034,1198058,1198217,1198379,1198400,1198402,1198410,1198412,1198413,1198438,1198484,1198577,1198585,1198660,1198802,1198803,1198806,1198811,1198826,1198829,1198835,1198968,1198971,1199011,1199024,1199035,1199046,1199052,1199063,1199163,1199173,1199260,1199314,1199390,1199426,1199433,1199439,1199482,1199487,1199505,1199507,1199605,1199611,1199626,1199631,1199650,1199657,1199674,1199736,1199793,1199839,1199875,1199909,1200015,1200019,1200045,1200046,1200144,1200205,1200211,1200259,1200263,1200284,1200315,1200343,1200420,1200442,1200475,1200502,1200567,1200569,1200571,1200599,1200600,1200608,1200611,1200619,1200692,1200762,1200763,1200806,1200807,1200808,1200809,1200810,1200812,1200813,1200815,1200816,1200820,1200821,1200822,1200824,1200825,1200827,1200828,1200829,1200830,1200845,1200882,1200925,1201050,1201080,1201160,1201171,1201177,1201193,1201196,1201218,1201222,1201228,1201251,1201381,1201471,1201524
CVE References: CVE-2021-26341,CVE-2021-33061,CVE-2021-4204,CVE-2021-44879,CVE-2021-45402,CVE-2022-0264,CVE-2022-0494,CVE-2022-0617,CVE-2022-1012,CVE-2022-1016,CVE-2022-1184,CVE-2022-1198,CVE-2022-1205,CVE-2022-1462,CVE-2022-1508,CVE-2022-1651,CVE-2022-1652,CVE-2022-1671,CVE-2022-1679,CVE-2022-1729,CVE-2022-1734,CVE-2022-1789,CVE-2022-1852,CVE-2022-1966,CVE-2022-1972,CVE-2022-1974,CVE-2022-1998,CVE-2022-20132,CVE-2022-20154,CVE-2022-21123,CVE-2022-21125,CVE-2022-21127,CVE-2022-21166,CVE-2022-21180,CVE-2022-21499,CVE-2022-2318,CVE-2022-23222,CVE-2022-26365,CVE-2022-26490,CVE-2022-29582,CVE-2022-29900,CVE-2022-29901,CVE-2022-30594,CVE-2022-33740,CVE-2022-33741,CVE-2022-33742,CVE-2022-33743,CVE-2022-33981,CVE-2022-34918
JIRA References: SLE-13513,SLE-13521,SLE-15442,SLE-17855,SLE-18194,SLE-18234,SLE-18375,SLE-18377,SLE-18378,SLE-18382,SLE-18385,SLE-18901,SLE-18938,SLE-18978,SLE-19001,SLE-19026,SLE-19242,SLE-19249,SLE-19253,SLE-19924,SLE-21315,SLE-23643,SLE-24072,SLE-24093,SLE-24350,SLE-24549
Sources used:
openSUSE Leap 15.4 (src):    dtb-aarch64-5.14.21-150400.24.11.1, kernel-64kb-5.14.21-150400.24.11.1, kernel-debug-5.14.21-150400.24.11.1, kernel-default-5.14.21-150400.24.11.1, kernel-default-base-5.14.21-150400.24.11.1.150400.24.3.6, kernel-docs-5.14.21-150400.24.11.1, kernel-kvmsmall-5.14.21-150400.24.11.1, kernel-obs-build-5.14.21-150400.24.11.1, kernel-obs-qa-5.14.21-150400.24.11.1, kernel-source-5.14.21-150400.24.11.1, kernel-syms-5.14.21-150400.24.11.1, kernel-zfcpdump-5.14.21-150400.24.11.1
SUSE Linux Enterprise Workstation Extension 15-SP4 (src):    kernel-default-5.14.21-150400.24.11.1
SUSE Linux Enterprise Module for Live Patching 15-SP4 (src):    kernel-default-5.14.21-150400.24.11.1, kernel-livepatch-SLE15-SP4_Update_1-1-150400.9.5.3
SUSE Linux Enterprise Module for Legacy Software 15-SP4 (src):    kernel-default-5.14.21-150400.24.11.1
SUSE Linux Enterprise Module for Development Tools 15-SP4 (src):    kernel-docs-5.14.21-150400.24.11.1, kernel-obs-build-5.14.21-150400.24.11.1, kernel-source-5.14.21-150400.24.11.1, kernel-syms-5.14.21-150400.24.11.1
SUSE Linux Enterprise Module for Basesystem 15-SP4 (src):    kernel-64kb-5.14.21-150400.24.11.1, kernel-default-5.14.21-150400.24.11.1, kernel-default-base-5.14.21-150400.24.11.1.150400.24.3.6, kernel-source-5.14.21-150400.24.11.1, kernel-zfcpdump-5.14.21-150400.24.11.1
SUSE Linux Enterprise High Availability 15-SP4 (src):    kernel-default-5.14.21-150400.24.11.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 54 Swamp Workflow Management 2022-08-01 13:25:28 UTC
SUSE-SU-2022:2615-1: An update that solves 48 vulnerabilities, contains 26 features and has 202 fixes is now available.

Category: security (important)
Bug References: 1055117,1061840,1065729,1071995,1089644,1103269,1118212,1121726,1137728,1156395,1157038,1157923,1175667,1179439,1179639,1180814,1183682,1183872,1184318,1184924,1187716,1188885,1189998,1190137,1190208,1190336,1190497,1190768,1190786,1190812,1191271,1191663,1192483,1193064,1193277,1193289,1193431,1193556,1193629,1193640,1193787,1193823,1193852,1194086,1194111,1194191,1194409,1194501,1194523,1194526,1194583,1194585,1194586,1194625,1194765,1194826,1194869,1195099,1195287,1195478,1195482,1195504,1195651,1195668,1195669,1195775,1195823,1195826,1195913,1195915,1195926,1195944,1195957,1195987,1196079,1196114,1196130,1196213,1196306,1196367,1196400,1196426,1196478,1196514,1196570,1196723,1196779,1196830,1196836,1196866,1196868,1196869,1196901,1196930,1196942,1196960,1197016,1197157,1197227,1197243,1197292,1197302,1197303,1197304,1197362,1197386,1197501,1197601,1197661,1197675,1197761,1197817,1197819,1197820,1197888,1197889,1197894,1197915,1197917,1197918,1197920,1197921,1197922,1197926,1198009,1198010,1198012,1198013,1198014,1198015,1198016,1198017,1198018,1198019,1198020,1198021,1198022,1198023,1198024,1198027,1198030,1198034,1198058,1198217,1198379,1198400,1198402,1198412,1198413,1198438,1198484,1198577,1198585,1198660,1198802,1198803,1198806,1198811,1198826,1198835,1198968,1198971,1199011,1199024,1199035,1199046,1199052,1199063,1199163,1199173,1199260,1199314,1199390,1199426,1199433,1199439,1199482,1199487,1199505,1199507,1199605,1199611,1199626,1199631,1199650,1199657,1199674,1199736,1199793,1199839,1199875,1199909,1200015,1200019,1200045,1200046,1200144,1200205,1200211,1200259,1200263,1200284,1200315,1200343,1200420,1200442,1200475,1200502,1200567,1200569,1200571,1200572,1200599,1200600,1200608,1200611,1200619,1200692,1200762,1200763,1200806,1200807,1200808,1200809,1200810,1200812,1200815,1200816,1200820,1200822,1200824,1200825,1200827,1200828,1200829,1200830,1200845,1200882,1200925,1201050,1201160,1201171,1201177,1201193,1201196,1201218,1201222,1201228,1201251,150300
CVE References: CVE-2021-26341,CVE-2021-33061,CVE-2021-4204,CVE-2021-44879,CVE-2021-45402,CVE-2022-0264,CVE-2022-0494,CVE-2022-0617,CVE-2022-1012,CVE-2022-1016,CVE-2022-1184,CVE-2022-1198,CVE-2022-1205,CVE-2022-1508,CVE-2022-1651,CVE-2022-1652,CVE-2022-1671,CVE-2022-1679,CVE-2022-1729,CVE-2022-1734,CVE-2022-1789,CVE-2022-1852,CVE-2022-1966,CVE-2022-1972,CVE-2022-1974,CVE-2022-1998,CVE-2022-20132,CVE-2022-20154,CVE-2022-21123,CVE-2022-21125,CVE-2022-21127,CVE-2022-21166,CVE-2022-21180,CVE-2022-21499,CVE-2022-2318,CVE-2022-23222,CVE-2022-26365,CVE-2022-26490,CVE-2022-29582,CVE-2022-29900,CVE-2022-29901,CVE-2022-30594,CVE-2022-33740,CVE-2022-33741,CVE-2022-33742,CVE-2022-33743,CVE-2022-33981,CVE-2022-34918
JIRA References: SLE-13513,SLE-13521,SLE-15442,SLE-17855,SLE-18194,SLE-18234,SLE-18375,SLE-18377,SLE-18378,SLE-18382,SLE-18385,SLE-18901,SLE-18938,SLE-18978,SLE-19001,SLE-19026,SLE-19242,SLE-19249,SLE-19253,SLE-19924,SLE-21315,SLE-23643,SLE-24072,SLE-24093,SLE-24350,SLE-24549
Sources used:
openSUSE Leap 15.4 (src):    kernel-azure-5.14.21-150400.14.7.1, kernel-source-azure-5.14.21-150400.14.7.1, kernel-syms-azure-5.14.21-150400.14.7.1
SUSE Linux Enterprise Module for Public Cloud 15-SP4 (src):    kernel-azure-5.14.21-150400.14.7.1, kernel-source-azure-5.14.21-150400.14.7.1, kernel-syms-azure-5.14.21-150400.14.7.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.