libvncserver Sicherheitslücke erreicht 9.8/10 und wurde lange nicht gefixt

„WOW“ entfleuchte es mir vorhin kurz, deswegen kommt Ihr jetzt in den Genuß einer drei Jahre alten Sicherheitslücke.

libvncserver Sicherheitslücke erreicht 9.8/10 und wurde lange nicht gefixt

Beim Durchsehen von Securityadvisories bei Red Hat Enterprise Linux stolperte ich über eine CVE Nummer aus 2017:

* libvncserver: websocket decoding buffer overflow (CVE-2017-18922)

For more details about the security issue(s), including the impact, a CVSS
score, acknowledgments, and other related information, refer to the CVE
page(s) listed in the References section.

Da nicht dabei stand, was da los war und wieso das erst jetzt gefixt wurde bei Red Hat, habe ich kurz recherchiert. Was dabei raus kam war diese Meldung von Red Hat:

Date: Tue, 30 Jun 2020 10:50:09 +0200
From: Stefan Cornelius <scorneli@...hat.com>
To: <eine Distri übergreifende ML>
Subject: libvncserver: old websocket decoding patch

Hi,

Upstream libvncserver fixed a websocket decoding issue >3years ago in
https://github.com/LibVNC/libvncserver/commit/aac95a9dcf4bbba87b76c72706c3221a842ca433

AFAICT, this never got a CVE and wasn't backported by some
distributions.

Thanks and kind regards,

[I sent a heads-up about this to distros last Friday, 'embargo' ran out
on Monday 20:00 UTC]
-- 
Stefan Cornelius / Red Hat Product Security

Da fixt also jemand eine drei Jahre alte Sicherheitslücke, weil die damals wohl keine CVE Nummer bekommen hatte, oder jemand diesen Umstand übersehen hat. (Könnte ja auch den besten mal passieren). Wäre das jetzt irgendeine schwer auszunutzende Lücke gewesen, hätte ich das achselzuckend abgehakt, aber das war es nicht.

In der NIST Datenbank findet sich nämlich das hier dazu:

It was discovered that websockets.c in LibVNCServer prior to 0.9.12 did not properly decode certain WebSocket frames. A malicious attacker could exploit this by sending specially crafted WebSocket frames to a server, causing a heap-based buffer overflow.

Severity

Base Score: 9.8 CRITICAL
Vector:  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.8 von 10.0 möglichen Punkten auf der Destruktionsskala, also eine leicht auszunutzende Lücke, die ohne Autorisierung am System funktioniert und eine Übernahme des Servers ermöglicht. Und DAS haben die übersehen… => WOW!
Als wenn das nicht schon genug wäre, kommt bei der Durchsicht der Updatemeldungen bei Fedora raus, das da gleich noch 3 andere jahrealte mit CVE Nummern versehen Sicherheitslücken gestopft wurden:
[ 1 ] Bug #1849877 – CVE-2019-20839 (Score 7.5) libvncserver: „ConnectClientToUnixSock()“ buffer overflow https://bugzilla.redhat.com/show_bug.cgi?id=1849877
[ 2 ] Bug #1849881 – CVE-2019-20840 (Score 7.5) libvncserver: unaligned accesses in hybiReadAndDecode can lead to a crash https://bugzilla.redhat.com/show_bug.cgi?id=1849881
[ 3 ] Bug #1849886 – CVE-2018-21247 (Score 7.5)  libvncserver: uninitialized memory contents are vulnerable to Information Leak https://bugzilla.redhat.com/show_bug.cgi?id=1849886
[ 4 ] Bug #1852356 – CVE-2017-18922 (Score 9.8) libvncserver: websocket decoding buffer overflow https://bugzilla.redhat.com/show_bug.cgi?id=1852356
Also das ist sicherheitstechnisch mal gründlich in die Hose gegangen. Jetzt denkt Ihr, betrifft mich nicht, ist ja Fedora und Red Hat.. leider Pech gehabt! betroffen sind auch:  OpenSUSE & Ubuntu. Man darf annehmen, daß Arch & Debian auch mit von der Partie sind. (kann ja mal kurz wer verifizieren, der die jeweiligen Updatesysteme kennt)

Quelle: https://nvd.nist.gov/vuln/detail/CVE-2017-18922
Quelle: https://www.openwall.com/lists/oss-security/2020/06/30/2

Wieder Baustelle auf dem Mittelweg

Es ist wieder mal soweit, eine Baustelle an der Einmündung Nordstraße/Mittelweg sorgt für Verkehrsprobleme.

Man sieht Absperrungen, Baustellenfahrzeuge, die EinmündungDie Arbeiten an einem Kabelschacht, der, oh Wunder der Koordination des Tiefbauamtes, keinen Meter von der letzten Baustelle aus Juli entfernt liegt, soll den Verkehr auf dem jeweils einseitig gesperrten Mittelweg und der Nordstraße bis zum 6.8.2020 beeinträchtigen. Hat man mir wenigstens versprochen 🙂

Mittelweg und Nordstraße sind jeweils einseitig nicht passierbar, die Nordstraße wurde allerdings zur Einbahnstraße erklärt. Wie man auf dem Foto sieht, kann man da jetzt nur noch rein fahren 🙁 Zu Staus oder ähnlichen Beeinträchtigungen wie beim letzten Mal, ist es heute noch nicht gekommen, trotz einsetzendem Feierabendverkehres.

CoronaChroniken: Einschätzung des Bundesamt für Arzneimittel

Moin Moin liebe Maskenträger,

bei der Quellenüberprüfung in Sachen Community-Maske ergab sich keine grundlegende Änderung seitens der Schutzwirkung von Community-Masken.

CoronaChroniken: Einschätzung des Bundesamt für Arzneimittel

Den aktuell gültigen Stand ( 26.6.2020 ) der Aussage findet Ihr hier:

„Schutzwirkung: i.d.R. nicht nachgewiesen;
durch das Tragen können Geschwindigkeit des Atemstroms oder Speichel-/Schleim-Tröpfchenauswurfs reduziert werden“ Quelle: bfarm.de – Schutzmasken.html

Auszug aus dem Digitalen Wörterbuch der Deutschen Sprache zu „können“ :

2. ⟨jmd. kann etw. tun⟩ drückt aus, dass der im Infinitiv genannte Prozess oder Zustand auf Grund bestimmter Umstände oder Voraussetzungen möglich ist

Für alle Nicht-Spachnerds, meint : „‚möglich ist‘ … aber nicht eintreten muß.“

Bevor mich jetzt jemand in den Topf mit dem Protestaufmarsch in Berlin am ersten August Wochenende wirft, ich bin nur gegen unsinnige Maßnahmen. Würden wir FFP Masken mit nachgewiesener Schutzwirkung bekommen (und ich damit noch kucken könnte wo ich hinlaufe) wäre ich wahrscheinlich sogar dafür, aber so wie es jetzt ist, ist es halt Quatsch. Gegen die <5µm Viruspartikel, welche stundenlang in der Luft schweben können, die die eigentliche Gefahr im Supermarkt sind, gegen die schützt die Stoff-Gesichtsmaske halt nicht.
Gegen eine Schmierinfektion, weil man seine Hände nicht von kontaminierten Flächen lassen konnte, und diese nun unbedingt zum Kratzen an der Nase benutzen muß, da wird diese Maske einen kleinen Beitrag leisten können. Allerdings ist das reiner Eigennutz, jemand anderen schützt man so nicht.

Aber ich kann ja viel schreiben, lassen wir doch mal die Experten zu Wort kommen:

Träger der beschriebenen Mund-Nasen-Bedeckungen können sich nicht darauf verlassen, dass diese sie oder andere vor einer Übertragung von SARS-CoV-2 schützen, da für diese Masken keine entsprechende Schutzwirkung nachgewiesen wurde.“ Quelle: bfarm.de – Schutzmasken Stand: 3.8.2020

Offizielle Bundesbehörde – offizielle Erklärung – QED.

Eine Aussage einer anderen Bundesbehörde gefällig? Bitte schön:

Bundesanstalt für Arbeitsschutz und Arbeitsmedizin:

Mund und Nasebedeckung“ – Einsatz für Private Nutzer : „denkbar¹“

¹) sinnvoll als ergänzende Maßnahmen zur allgemeinen Hygiene- und der Abstandsempfehlung, für alle Personen im öffentlichen Raum einschließlich der Beschäftigten

Stand: 12.6.2020  Quelle: baua.de – Schutzmasken.pdf

Synonyme für „denkbar“ : „vielleicht“, „möglicherweise“, „nicht ausgeschlossen“, „kann sein“, „soll vorkommen“, usw. „Wissen“ und „Schutz“ sieht anders aus 😉

Für Personal, welches mit Infizierten oder auch nur Verdächtigen arbeiten muß, wird übrigens im gleichen PDF eine FFP3 Maske empfohlen, weil das Schutzniveau der anderen Masken nicht ausreicht. Warum machen sich die Leute also noch etwas vor?

Da habe ich einigen Tagen eine schöne Erklärung für gehört: Es liegt am Verlangen des Menschen Kontrolle über sich und sein Schicksal auszuüben. Dies führte direkt zum Regentanz, Opferungen und anderem Unsinn. A hat halt nicht immer was mit B zu tun.

Kernel 5.7.8+ Problem entdeckt

Es ist mal wieder soweit, ein fieses Kernelproblem wurde entdeckt. Ja ok, passiert dauernd, aber meisten sind nicht alle davon betroffen, hier schon, da es ein Speicherzugriffsfehler ist.

Kernel 5.7.8+ Problem entdeckt

In den letzten zwei Tagen sind zwei verschiedene Computer mit dem gleichen Fehlerbild stehen geblieben:

Aug 2 18:01:17 shortname kernel: BUG: unable to handle page fault for address: ffff8881e2e48630
Aug 2 18:01:17 shortname kernel: #PF: supervisor write access in kernel mode
Aug 2 18:01:18 shortname kernel: #PF: error_code(0x0003) – permissions violation

Der PC bleibt dabei nicht gleich stehen, sondern der Zugriff auf Strukturen im /proc Filesystem ( procfs ) friert einfach ein. Als Resultat bleiben Programme wie „top“ oder „pidof“ stecken. Das ist besonders blöd, weil „pidof“ beim Startprozess eines Terminals für die Bash mitmischt und man so keins mehr starten kann.

Ich hatte erst gedacht, daß wäre ein VM Problem, weil es zunächst im Servercluster aufgetreten ist, aber da es jetzt auch bare-metal auf einem Desktop-PC passiert ist, was es Zeit Alarm zu schlagen.

Wer Kernel 5.7.8 einsetzt kann sich derzeit nicht sicher sein, daß der PC durchläuft. Bei mit lag der Ausfallzeitpunkt bei knappen 15 Stunden Betriebszeit für bare-metal und ~2 Wochen für eine VM in der heute das gleiche passiert ist. Da das Problem frisch entdeckt wurde, gibt es noch keine Reaktion vom Kernel Team. Ich kann aber nur dazu raten einen anderen Kernel lauf zu lassen.

Wenn Ihr das Problem rechtzeitig bemerkt, könnt Ihr noch über die Desktop-Systemüberwachung in die Prozessliste und die „pidof“ Prozesse abbrechen, die das Starten eines Terminals verhindern. Danach kommt die Bash i.d.r. sauber hoch und Ihr könnt Reboot eingeben. Ein „systemctl reboot -i“ wird nötig sein, da der normale Reboot, zumindest bei mir, verweigert wurde.

Hier für Euch die ganze Kernelmeldung für Vergleichszwecke:

Aug 2 18:01:17 shortname kernel: BUG: unable to handle page fault for address: ffff8881e2e48630
Aug 2 18:01:17 shortname kernel: #PF: supervisor write access in kernel mode
Aug 2 18:01:18 shortname kernel: #PF: error_code(0x0003) – permissions violation
Aug 2 18:01:18 shortname kernel: PGD 2a0c067 P4D 2a0c067 PUD 3800067 PMD 1ffff2067 PTE 100001e2e48065
Aug 2 18:01:19 shortname kernel: Oops: 0003 [#3] SMP NOPTI
Aug 2 18:01:19 shortname kernel: CPU: 0 PID: 96 Comm: kswapd0 Tainted: G D W 5.7.8-100.fc31.x86_64 #1
Aug 2 18:01:19 shortname kernel: RIP: e030:ptep_clear_flush_young+0x1d/0x30
Aug 2 18:01:19 shortname kernel: Code: 48 0f ba 32 05 0f 92 c0 0f b6 c0 c3 90 0f 1f 44 00 00 48 8b 05 ec 74 40 01 48 25 00 f0 ff ff 48 f7 d0 48 23 02 83 e0 20 74 0c <f0> 48 0f ba 32 05 0f 92 c0 0f b6 c0 c3 66 0f 1f 44 00 00 0f 1f 44
Aug 2 18:01:19 shortname kernel: RSP: e02b:ffffc90001127a48 EFLAGS: 00010202
Aug 2 18:01:19 shortname kernel: RAX: 0000000000000020 RBX: ffff888101c64ed8 RCX: 0000000000000000
Aug 2 18:01:19 shortname kernel: RDX: ffff8881e2e48630 RSI: 00007fe123ac6000 RDI: ffff888101c64ed8
Aug 2 18:01:19 shortname kernel: RBP: ffffea00049c2e80 R08: 0000000000000101 R09: 0000000000000125
Aug 2 18:01:19 shortname kernel: R10: ffff8881f483e8d0 R11: ffffea0005ddc2a0 R12: ffffc90001127b08
Aug 2 18:01:19 shortname kernel: R13: 0000000000000000 R14: 00007fe123ac6000 R15: 0000000000000186
Aug 2 18:01:19 shortname kernel: FS: 00007f37db3a7700(0000) GS:ffff8881f5c00000(0000) knlGS:0000000000000000
Aug 2 18:01:19 shortname kernel: CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630 CR3: 0000000002a0a000 CR4: 0000000000040660
Aug 2 18:01:19 shortname kernel: Call Trace:
Aug 2 18:01:19 shortname kernel: page_referenced_one+0x59/0x150
Aug 2 18:01:19 shortname kernel: rmap_walk_file+0x157/0x2f0
Aug 2 18:01:19 shortname kernel: page_referenced+0xdb/0x150
Aug 2 18:01:19 shortname kernel: ? rmap_walk_file+0x2f0/0x2f0
Aug 2 18:01:19 shortname kernel: ? page_get_anon_vma+0x80/0x80
Aug 2 18:01:19 shortname kernel: shrink_active_list+0x2e5/0x560
Aug 2 18:01:19 shortname kernel: shrink_lruvec+0x3b9/0x6b0
Aug 2 18:01:19 shortname kernel: ? do_shrink_slab+0x52/0x2c0
Aug 2 18:01:19 shortname kernel: shrink_node+0x169/0x680
Aug 2 18:01:19 shortname kernel: balance_pgdat+0x2d9/0x5c0
Aug 2 18:01:19 shortname kernel: kswapd+0x1ed/0x3a0
Aug 2 18:01:19 shortname kernel: ? __schedule+0x2c2/0x730
Aug 2 18:01:19 shortname kernel: ? finish_wait+0x80/0x80
Aug 2 18:01:19 shortname kernel: kthread+0xf9/0x130
Aug 2 18:01:19 shortname kernel: ? balance_pgdat+0x5c0/0x5c0
Aug 2 18:01:19 shortname kernel: ? kthread_park+0x90/0x90
Aug 2 18:01:19 shortname kernel: ret_from_fork+0x35/0x40
Aug 2 18:01:19 shortname kernel: Modules linked in: fuse btrfs blake2b_generic xor raid6_pq hfsplus hfs minix vfat msdos fat jfs xfs nfsv3 nfs_acl nfs lockd grace fscache xt_owner ipt_REJECT nf_reject_ipv4 xt_connlimit nf_conncount nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c xt_multiport ip6table_filter ip6_tables cls_u32 sch_htb iptable_filter intel_rapl_msr intel_rapl_common cfg80211 sb_edac x86_pkg_temp_thermal coretemp crct10dif_pclmul rfkill crc32_pclmul ghash_clmulni_intel intel_rapl_perf sunrpc ip_tables xen_netfront xen_blkfront crc32c_intel
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630
Aug 2 18:01:19 shortname kernel: —[ end trace 7fb962ee698fa150 ]—
Aug 2 18:01:19 shortname kernel: RIP: e030:unmap_page_range+0x631/0xec0
Aug 2 18:01:19 shortname kernel: Code: fe e8 03 f8 ff ff 48 83 7c 24 18 00 48 89 c3 74 09 48 85 c0 0f 85 c0 05 00 00 41 f6 44 24 20 01 0f 84 25 03 00 00 4c 8b 6d 00 <48> c7 45 00 00 00 00 00 4d 39 7c 24 10 4c 89 f8 49 0f 46 44 24 10
Aug 2 18:01:19 shortname kernel: RSP: e02b:ffffc90002a2bb38 EFLAGS: 00010202
Aug 2 18:01:19 shortname kernel: RAX: ffffea0001b72500 RBX: ffffea0001b72500 RCX: 0000000000000125
Aug 2 18:01:19 shortname kernel: RDX: 0000000000000000 RSI: 00005589f49e7000 RDI: 000000083aa94125
Aug 2 18:01:19 shortname kernel: RBP: ffff8881e3d90f38 R08: ffff88810011e320 R09: 0000000000000000
Aug 2 18:01:19 shortname kernel: R10: 0000000000007ff0 R11: 0000000000000000 R12: ffffc90002a2bc80
Aug 2 18:01:19 shortname kernel: R13: 000000083aa94125 R14: 00005589f49e8000 R15: 00005589f49e7000
Aug 2 18:01:19 shortname kernel: FS: 00007f37db3a7700(0000) GS:ffff8881f5c00000(0000) knlGS:0000000000000000
Aug 2 18:01:19 shortname kernel: CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630 CR3: 0000000002a0a000 CR4: 0000000000040660

 

CoronaChroniken: Infizierte sind nicht zwangsweise Kranke oder Tote

Liebe Maskierte,

ich hab da mal eine kleine Umfrage für Euch gestartet, weil meine Frage nicht in der Lancet-Studie über Corona in Deutschland beantwortet wurde.

CoronaChroniken: Infizierte sind nicht zwangsweise Kranke oder Tote

Meine Frage war ursprünglich, sterben jetzt eigentlich immer gleich viele Menschen an/mit Covid-19 oder hat die Sterberate abgenommen?

Dazu braucht man erstmal die Sterbezahlen und rein praktisch, auch die Verweildauer der Patienten im Krankenhaus. Die AOK, welche die im Lancet veröffentlichte Studie unterstützt hat, war so freundlich mir die Zahlen zu übermitteln:

Die gestorbenen Patienten liegen im Durchschnitt 12,8 Tage im Krankenhaus. Bei den beatmeten verstorbenen sind es 16,4 Tage, bei den nicht beatmeten Patienten sind es 10,3 Tage.
Wie lange die Patienten nach der Diagnosestellung bis zu Ihrem Krankenhausaufenthalt noch zu Hause waren, ist nicht bekannt.

Viele Grüße

Carina Mostert
Forschungsbereichsleiterin

Forschungsbereich Krankenhaus
Wissenschaftliches Institut der AOK (WIdO)

Es gibt also einen Unsicherheitsfaktor, aber wir können mit 14 Tagen rechnen. Nicht geantwortet hatte übrigens: das RKI. Nun brauchen wir die Zahlen der Leute die als Covid-19 Verstorbene gelten, die gibts beim Bundesamt für Statistik:

https://www.destatis.de/DE/Themen/Querschnitt/Corona/Gesellschaft/kontextinformationen-gesellschaft.html

Leider gibt es die Zahlen nur Wochenweise, was in Verbindung mit den täglichen Infiziertenzahlen zu einem, sagen wir es mal vorsichtig, gewöhnungsbedürftigen Graphen geführt hat:

Ein vergleich zwischen den Gestorbenen und den InfiziertenTrotzdem ist der Graph sehr aufschlussreich, da er anzeigt, daß zu Beginn der Pandemie die Leute im gleichen Maße wie die Neuinfiziertenzahlen gestiegen bzw. gefallen sind. Der Ausbruch bei Tönnies Mitte Juni hatte keine Zunahme der Sterbezahlen zur Folge … die Zahlen sind sogar weiter gesunken! Aus dem Graphen und den Zahlen der AOK kann man ablesen, daß auch drei Wochen nach dem Anstieg die Zahlen der mit Verbindung zu Corona verstorbenen weiter abnimmt. Drei Wochen sind als Zeitraum deswegen wichtig, weil die durchschnittliche Sterbedauer der Patienten 12,8 Tage (+7 Tage Inkubationszeit) beträgt und innerhalb der drei Wochen defakto Menschen hätten sterben müssen. Was nicht klar ist, ist die Frage, ob die ausländischen Hilfsarbeiter in ihren Ländern an der Infektion verstorben sind, so sie sich überhaupt absetzen konnten. Ein kleiner Unsicherheitsfaktor bleibt hier also im Spiel.

Schlußfolgerung

Das Virus ist entweder so mutiert, daß es weniger tödlich ist, oder die Behandlung wurde erfolgreich verbessert (unwahrscheinlich). Sollte der Virus nicht mutiert sein, dann hatten einige einfach Glück, daß sie in dieser Statistik nicht auftauchen ( Quarantäneerfolg z.B. ) oder die, die für einen tödlichen Ausgang empfänglich waren, sind jetzt bereits tod und können nicht nochmal sterben. Würde letzteres zutreffen, wären alle allgemeinen Maßnahmen zur Ausbreitungskontrolle überflüssig geworden. Auf die Maßnahmen zum Schutz von Risikopatienten hätte das keinen Einfluß.

In ca. drei Wochen wissen wir mehr, was genau der Fall ist, denn dann kommen die Sterbezahlen für den aktuellen Anstieg in die Destatis Auswertung und sollte es auch dort keine zusätzlichen Covid-19 Opfer geben, wäre der Fall klar: Virus Richtung harmlos mutiert oder empfängliche Personen bereits verstorben, denn diesmal ist es kein örtlich begrenzter Herd wie bei Tönnies, sondern aufs gesamte Bundesgebiet verteilt (mit örtlichen Schwerpunkten ). Dann könnten wir eine zügige Normalisierung einleiten und einfordern.

Ich bin optimistisch, daß es auch beim aktuellen Anstieg nicht zu viel-mehr neuen Toten kommen wird. Mit einigen wenigen werden wir aber leider rechnen müssen, da der aktuelle Anstieg andere Gruppen von Menschen getroffen hat, als Menschen im arbeitsfähigen Alter oder kurz „Nicht-Risikogruppe“ wie bei Tönnies. Das es derzeitig überhaupt noch Tote gibt, die Corona zugerechnet werden, liegt auch in dem Umstand begründet, daß das RKI nicht von seiner Politik „Einmal Corona nachgewiesen, immer an Corona gestorben“ abweichen will. Ich halte diese Regel für komplett falsch. Andere Länder sind da weiter: CoronaChroniken: Auch England hat die Statistiken überhöht

Das RKI

Ich finde auch eine Aussage in der letzten RKI-Pressekonferenz von Herrn Wiehler für höchst bedenklich: „Wir dürfen die Maßnahmen ( gemeint sind Maske, Hygiene, Abstand ) nicht hinterfragen!“

Doch Herr Wiehler, das dürfen, nein, das müssen wir sogar! Jeden Tag müssen wir die Zahlen auf die Probe stellen und die Maßnahmen und Entscheidungen überdenken, denn so wie es jetzt ist, ist es für alle nicht gut. Wenn die Implosion von insolventen Unternehmen wie erwartet jetzt im August (durch Auslaufen der Schutzmaßnahmen) stattfindet, dann wird es sogar richtig schlimm für alle!

PS: Ihr glaubt gar nicht, wie mir dieser Artikel unter den Nägeln gebrannt hat 🙂 Ich habe die Analyse rund 8 Tage zurückhalten müssen, weil das Bundesamt mit seinen Zahlen nicht nachgekommen ist 😀 die nächsten drei Wochen werden also seeeeeehr spannend 🙂

Kleine Fun Fakt am Rande: Das RKI zeigt in seiner Dashboard Darstellung der Neuinfizierten immer an, wenn frühere Tage nach oben korrigiert wurden. Was der Graph nicht darstellt ist der Fakt, daß die Zahlen auch nachträglich nach UNTEN geändert werden. Da ich die Zahlen aus dem Graphen übernehme und abgleiche, bevor ich die neuen Grafiken erstelle, bemerke ich das natürlich. Guter Transparenz ist das Verhalten des RKI leider nicht zuträglich, ein Trend zum „nach oben“ könnte natürlich auch gewollt sein 😉

Boothole – Ja, und?

Ähm.. ich fühle mich geradezu .. ähm.. genötigt.. auch was zum Grubproblem zu schreiben:

Ja, und?

Als ich bei Heise das erstmal davon gelesen hatte, ging mir nur das Satzfragment „ja,und?“ durch den Kopf? Was bitte ist an einer Lücke mit der einen PC „übernehmen“ kann, für die man aber schon Root sein muß, besonders? Naja, nichts. Wenn ich schon durch einen Hack Root wurde, dann brauche ich diese Lücke nicht mehr, weil ich schon drin bin. Wenn man diese Lücke von außen per physischem Zugriff ausnutzen kann, dann brauche ich das auch nicht mehr, denn dann hatte ich schon den Zugriff auf den PC mit allem was drauf ist, denn die meisten haben keine Festplattenvollverschlüsselung. Ich kann als Angreifer also nicht nur den Bootbereich, sondern alles ändern, wenn ich das wollte.

Es bleibt also nur die eine Kombination übrig, für die das ein Problem ist: Systeme mit Verschlüsselung + physikalischem Zugriff  und hier auch nur die, wo /Boot unverschlüsselt ist.

Jetzt ist das mit dem physischem Zugriff so eine Sache, denn was bitte hindert mich daran, einen Bootloader auf die Platte zu bannen und dem Bios des Pcs zusagen, es soll Legacy booten, ergo der Secureboot ist nicht mehr im Spiel? Ein BIOS-Passwort vielleicht? Nicht wirklich, weil physischer Zugriff meint halt auf alles, ich könnte als Angreifer also auch mit genug Zeit, das Mainboard austauschen und so das Biospasswort umgehen, oder ich resette das einfach.

Antwort von Euch: „Dann schließ das Gehäuse halt ab.“ .. ja, das ist so.. ich war mal bei den deutschen Meisterschaften im Schlösserknacken dabei ( Zuseher ) und naja, so sicher wie man glaubt,  sind Schlösser gar nicht. Türschlösser z.b. sind in unter 3 Sekunden geöffnet. Es gibt sogar einen Sportverein der sich ganz der Schlossknackkunst verschrieben hat. Wenn uns das eins lehrt: Schlösser sind kein Hindernis für Profis und die (baulich)einfachen Schlösser von PC Gehäusen oder ausm Baumark schon gar nicht.

Merke.. wer physischen Zugriff auf Euren PC hatte, stellt IMMER ein unkalkulierbares Risiko da. Daher kann einen diese Lücke nicht wirklich schrecken. Spannender wird die Frage, wie M$ das nötige Secure-Bootupdate für die Sperre alter Grub Shims verteilen möchte, weil ohne das, ist der Fix oder nicht Fix komplett unwichtig 😀

Krita 4.3.0 fehlt der untere Scrollbar

Moin,

in Krita wurde ein lästiges kleines Problem entdeckt, daß bei der Bildbearbeitung echt nervig sein kann.

Krita 4.3.0 fehlt der untere Scrollbar

Wenn Ihr mal in diese Grafik schauen möchtet, dann achtet mal auf den unteren Rand vom Bearbeitungsfeld mit dem Bild drin:

Das Grafikbearbetitungsprogramm Krita geöffnet mit einem Bild, es fehlen die horizontalen BalkenRechts sieht man den vertikalen Scrollbalken, aber der horizontale fehlt.

Wie bekommt Ihr das Bild jetzt bewegt, so daß Ihr z.b. sauber ausschneiden könnt?

Da gibt es jetzt zwei Wege das Problem zu lösen:

1) Ihr benutzt das Move-Tool, das ist das kleine Seefahrer Kreuz in der Iconleiste von Krita

oder 2) Ihr schaltet die Leiste von Cinnamon ab, denn einer Eingebung folgend, habe ich auf Verdacht mal nachgesehen, ob nicht einfach das Fenster hinter der Leiste ist, was es war 😀Es wird ein Bild ohne Iconleiste den Windowmanagers Cinnamon gezeigt, das beweißt, daß die horozontale Scrollbar unter der Leiste von Cinnamon liegtWer genau hinschaut, sieht am unteren Rand noch einige andere „Rahmen“. Leider war ich nicht in der Lage die auch komplett sichtbar zu machen.

Bei Cinnamon als Fenstermanager könnt Ihr die Leiste „intelligent oder Automatisch ausblenden“ lassen. Einstellen kann man das in den Leisteneinstellungen, die man mit rechtem Mausklick auf die Leiste oder per Einstellungsmenü von Cinnamon erreicht:

Auf gleichen Wege kann man die Leiste später auch wieder permanent sichtbar machen. Bugreport ist raus, schauen wir mal. ggf. wars auch nur ein Glitch und das fängt sich wieder.

 

CoronaChroniken: Covid-19 ist ein Problem für Alte

Guten Morgen,

gute Nachrichten für alle Eltern unter 45 Jahren: Kinder unter 15 sterben seltener als in 2019.

CoronaChroniken: Covid-19 ist ein Problem für Alte

Die unter 15jährigen Kinder der Eltern über 45 sterben zwar genauso selten in 2020, aber leider gilt das nicht für sie selbst. Bei den Kinder haben wir bis Woche 29/2020 in Westeuropa +39 Tote zu viel, also mehr als normal wären. Bis Woche 29/2019 waren es dagegen schon +226. Im Jahre 2018 wiederum nur -48, da sind als deutlich weniger gestorben als normal wäre. Wäre bestimmt spannend rauszubekommen, wieso das so war. Leider hielt der Trend in 2018 nicht, am Ende des Jahres waren es in Summe +120 Tote Kinder zu viel.

Bei den Eltern bis 45 liegt 2020 allerdings vorn, da sind es in 29/2020 +1.882 Tote. Richtig schlimm wird es über 45 Jahre, mit +16.195 bei den 45-64 jährigen und +25.247 bei den 65-74 jährigen. Ganz schlimm hat es die 74-84 jährigen getroffen: +61.010 und bei den über 85 Jahre alten Menschen lag die Zahl bei +91.228.

Diese Zahlen sind eine Aufsummierung von 1/2020 bis 29/2020, der rapide Anstieg war bis Woche 20/2020, seitdem stagnieren die Zahlen überall, außer bei den Kindern, da gehen sie weiter zurück.

Kurze Ansage für alle, die den Virus Covid-19 an sich leugnen wollen: Im gesamten Grippejahr 2018 ( +121.927 ) sind knapp 70.000 Menschen weniger gestorben als bis Woche 29/2020 bereits verstorben sind ( +197.646 ). Den Virus gibt es also. Das er nicht für alle Altersgruppen gleich gefährlich ist, ist eine andere Sache.

Kommentar

Die Wochen 11/2020 bis 19/2020 werden vermutlich als Todeswochen in die Geschichte eingehen. Woche 15/2020 markiert den Wendepunkt und zugleich die Spitze der Sterbewelle. Die Maskenpflicht wurde erst Ende Woche 17/2020 eingeführt, da war die Sterbekurve bereits massiv zusammengebrochen. Wenn man von 3-4 Wochen Behandlungsdauer bei schweren Verläufen ( die zum Tod führen ) berücksichtigt, dann haben sich die Gestorbenen in Woche 6-10 (Inkubationszeit ~7-10 Tage beachtet) angesteckt. Und wieder ein Indiz, daß die Maskenpflicht politischer Aktionismus ist.

Das es Deutschland und andere Länder nicht so hart getroffen hat, wie Spanien, Frankreich, England, Italien, muß andere Ursachen haben, als reine Abschottung, denn das Virus war ja bereits im Land. Es wäre wirklich Spannend da die wahren Ursachen, seien es Behandlungsfehler, Verhaltensweisen, Mangelernährung oder Demographie, herauszufinden.

Da wo Schatten ist, gibt es ja auch immer Licht, daher möchte ich hier nochmals darauf hinweisen, daß man Covid-19 auch mit über 100 Jahren noch überleben kann. Wichtig ist eine gesunde Ernährung, ein trainiertes Immunsystem zur Abwehr der Angreifer und wenige Vorerkrankungen, also alles, was man ohnehin braucht um überhaupt 100 zu werden 😉

Wer über 60 Jahre alt ist, sollte sich bei Viruswellen und anderen Infektionsquellen ohnehin immer etwas besser schützen als die jüngeren. Aber unsinnige Maßnahmen helfen keinem. Abstand halten, Kontakt vermeiden, ordentlich ernähren und hygienisch handeln, sind sinnvolle Maßnahmen.

Datenquelle: https://euromomo.eu/graphs-and-maps/

CoronaChroniken: Für diese Welle braucht es eine Lupe

Guten Morgen,

ich sage ja immer lasst Zahlen sprechen, aber die muß man auch lesen können 😉

CoronaChroniken: Für diese Welle braucht es eine Lupe

Fangen wir mit Pressezitaten an:

„Sehr beunruhigend“ fand das Rober-Koch-Institute die jüngsten Corona-Ifiziertenzahlen“.

und

„Ministerpräsident Michael Kretschmer (CDU). „Die zweite Corona-Welle ist schon längst da. „

Quelle für beides: www.welt.de/politik/deutschland/article212210173 (25.4.2020)

Andere Zeitungen berichten ähnlich, da gehe ich jetzt mal davon aus, daß die die gleiche Quelle zitieren.

Da kann man leider nur folgendes zu sagen: „Ähm, nein.“, weil, diese Welle müßte man derzeit noch mit der Lupe suchen. Schauen wir uns mal die Zahlen grafisch an:

Ich habe in der Euch bekannten Grafik die beiden anderen Linien auf weiß gestellt, daß das man nur die relevanten wahr nimmt. Ich habe keine Lust laufend neue Grafiken zu erstellen in Calc, nur weil eine Info mal nicht so wichtig ist 😉

Ihr seht den roten Huckel im R um den 17.6. rum? Tönnies. Ihr seht wie stark der ist? Das lag an den Meldezahlen, die sahen so aus:

(Quelle: https://npgeo-de.maps.arcgis.com – RKI)

Weil es hier einen Sprung von 500 auf 1000 Meldungen gab, sprangt der R-Graph auch heftigst. Der rechnet das Verhältnis zwischen Vortagen zu Jetzt aus. Hier die Zahlen in absoluten Werten:

13.06.20295
14.06.20169
15.06.20262
16.06.20540
17.06.20990
18.06.20630
19.06.20888
20.06.20530
21.06.20260
22.06.20488

Eine Formel für den R Wert sieht so aus:  R = Summe( T-3: T-0 ) / Summe(T-8:T-4)  ( T= Tag ). Das kann man auch mit 7 Tagen (meine Version im Graphen ist eine andere) machen, dann wird es stärker geglättet. Jetzt schwankt das R deswegen so stark, weil die Mathematik das bei kleinen Ganzzahlen so vorschreibt. „Ganzzahlen“ übrigens, weil halbe Menschen gibt es nicht 😉 Brüche können also nicht vorkommen in der Summenbildung, im Ergebnis allerdings schon.

Mit den Zahlen oben, kleine Beispielrechnung:
(Hinweis: die Zahlen hier sind größer, weil die Ausgangsdaten nicht geglättet wurden)

20.6. ( 3038 ) / ( 1266  ) = 2,399684044
21.6  ( 2308 ) / ( 1961 ) = 1,176950535
22.6. ( 2166 ) / ( 2422 ) = 0,89

Jetzt sagen wir mal, es wären am 20.6. nur 30 / 12 gewesen = 2,5 und am 21.6 käme raus = 1,21 und am 22.6 wären es dann 0,875 . Jetzt das ganz mit noch kleineren Zahlen:  3/1 = 3,  2/1 = 2 und 2/2 = 1 .

Man sieht, die Schwankung der Zahlen hängt von dem absoluten Wert ab. Je kleiner der Wert, der größer die Ungenauigkeit im Ergebnis. Jetzt machen wir das mal mit größeren Zahlen:

( 30380 / 12660 ) = 2,399 … ups, das ist das gleiche Ergebnis wie oben, weil beide Werte in der Bruchrechnung nur mit 10 vergrößert wurden. Das hatte keinen Einfluß mehr, weil die absoluten Zahlen einen Grenzwert über die Genauigkeit des Ergebnisses überschritten hatten und sich das „*10“ natürlich wegkürzt ;).

Ergebnis: Wenn die absoluten Zahlen zu klein werden, dann kommen größere Schwankungen im R raus, weil die Genauigkeit nicht mehr gegeben ist. Ab einem bestimmten absoluten Wert, machen Rechnungen so keinen Sinn mehr!

Woran kann man das jetzt anschaulich sehen?

Das ist die Grafik zur prozentualen Schwankung ( rote Linien ) der Tageswerte von Neuinfizierten ( blaue Linien ):

Ihr seht, wie am Anfang, als die absoluten Zahlen noch klein waren, die roten Linien stark schwanken? Das ist zum einen der Effekt der kleinen Ganzzahlen, zum Anderen der wirklich starke Anstieg der Infizierten Zahlen. Das machte in Summe die prozentualen Anstiege sehr groß.

Wenn wir uns hier den 16.6.  in der dunkelroten Linie ansehen, schwanken de Tageswerte um biszu +20% gegenüber dem Vortag. Die absolute blaue Kurve der selben Zahlen unten dagegen, schwankt nur leidlich. Wenn man solche Effekte der zugrundliegenden Mathematik nicht beachtet, sagen prozentuale Schwankungen nicht viel aus. Da R auch nur ein Verhältniswert ist, genau wie Prozente, gelten da die gleichen Regeln.

Deswegen bleibe ich immer entspannt, wenn jemand ruft, „der R Wert ist über 1“ .. „krasse Änderung von R!“ „Wir werden alle Sterben“  .. ok 🙂 Werden wir nicht. Ihr wisst ja jetzt, beide Werte muß man im Auge haben um Panik zu vermeiden. Es ist auch zu erwarten, daß das Basisrauschen an Infizierten das ganze Jahr so weitergeht. Der Wert wird immer wieder schwanken. Das ist normal.

Die zweite Welle ist vielleicht schon die dritte

Den Anstieg, den Herr Kretschmar da sieht (und ihr hoffentlich auch) ist also nicht mal so groß wie beim Fall „Tönnies“. Natürlich kann sich die Infiziertenzahl weiter vergrößern und der Anfang eines größeren Berges werden, wissen tun wir das aber noch nicht. Auch wenn mein persönlicher R Wert 2 Tage in die Zukunft schaut, bleibt das nur eine Schätzung, mehr nicht. Eigentlich ist es auch eher eine Erwartung und die kommt bekanntlich auf den Erwartenden an 😉

Es spielt eh keine Rolle, wir werden diesen Virus alle früher oder später bekommen, falls er nicht zu einem neuen Virus mutiert, bevor Ihr den hattet. Das ist schließlich ein Virus, den interessieren unsere Maßnahmen nur begrenzt solange es keine Impfung gibt oder wir uns alle 4 Wochen in ein Loch eingraben und zwar jeder für sich. Auch wenn das immer so hart und herzlos klingt, aber die Masse der Bevölkerung hat bestenfalls eine grippeartige Erkrankung zu erwarten, auch wenn daran dann leider einige sterben werden.

Durch den Lockdown und die Vermeidung von Toten, wird es jetzt im Laufe des Jahres auch immer wieder zu, für sich genommen, größeren Herden mit Infizierten und ja auch Toten kommen. Das ist unvermeidbar ohne Impfstoff, ob Ihr mit Stofftuch vor der Nase rumrennt oder nicht. Hätte man die 1. Welle ausgesessen ohne Lockdown, wären die Toten die jetzt noch kommen, bereits tot.

Machtlosigkeit

Mir ist klar, daß viele Menschen nicht damit zurecht kommen, machtlos dem eigenen Tod gegenüber zu sein, aber wenn die Zeit für einen gekommen ist, dann ist sie gekommen. Da kann man nichts machen. Sprecht mal mit Menschen die auf Intensivstationen arbeiten oder im Altenheim. Die werden das bestätigen. Wir können den Punkt des Todes zwar manchmal etwas hinauszögern, aber das Ende kommt sicher, todsicher sogar.

Aus dieser Machtlosigkeit dem Unvermeidbaren gegenüber, ist übrigens auch die Maskenpflicht entstanden. „Wir müssen was tun! Egal was.“ Menschen reden sich dann auch immer ein, daß das was sie getan haben, einen Zusammenhang hat mit dem was dann geschieht. So ist der Regentanz entstanden, Religion, Aberglaube, hat alles den gleichen Ursprung: das völlige versagen, die Unwichtigkeit des eigenen Handelns der Welt gegenüber zu erkennen. Ab hier übergebe ich an die Philosophen 🙂

Mein Rat: ernährt Euch gut, entspannt Euch, nehmt weniger Drogen, treibt etwas Sport, geht an die Sonne, schlicht und einfach: gebt Euch die besten Chancen eine Krankheit zu überleben, wenn sie kommt. Das hilft sogar gegen anderen Viren 😉

Nvidia: Fehlercodes

Seit einigen Wochen nervt meine GTX 1050, eine schöne Gelegenheit Euch mal das Nvidia Fehlersystem näher zu bringen.

Nvidia: Fehlercodes

Zuerst müssen wir natürlich erstmal wissen, welcher Fehler überhaupt aufgetreten ist. Dazu braucht es nur dmesg:

$ dmesg |grep Xid
[ 5552.987812] NVRM: Xid (PCI:0000:01:00): 32, pid=1550, Channel ID 00000033 intr 00040000
[ 5731.173383] NVRM: Xid (PCI:0000:01:00): 32, pid=11658, Channel ID 00000033 intr 00040000
[ 5731.173633] NVRM: Xid (PCI:0000:01:00): 32, pid=11658, Channel ID 00000033 intr 00040000
[ 6326.298292] NVRM: Xid (PCI:0000:01:00): 32, pid=11982, Channel ID 00000033 intr 00040000
[ 6326.298525] NVRM: Xid (PCI:0000:01:00): 32, pid=11982, Channel ID 00000033 intr 00040000

Wie bei allen Kernelmeldungen steht am Anfang die Kernelzeit in Sekunden seit dem Boot. Danach kommt als erstes die PCI ID des Gerätes, aber da selten jemand zwei oder mehr Grafikkarten im PC hat, ist das für die meisten uninteressant. Der Fehlercode selbst ist die unscheinbare Zahl nach der PCI ID, hier „32“.

Auf der Webseite von Nvidia: xid errors findet sich dann die Beschreibung für den Fehler und erste Hinweise zur Ursache:

XIDFailureCauses
HW ErrorDriver ErrorUser App ErrorSystem Memory CorruptionBus ErrorThermal IssueFB Corruption

31

GPU memory page fault

X

X

32

Invalid or corrupted push buffer stream

X

X

X

X

X

Xid 32 meint also, daß der Datenstrom zu Grafikkarte unterbrochen wurde. Mögliche Ursachen: Der Graka-Speicher ist defekt, der PCI Bus hat ne Macke oder irgendwas ist überhitzt. (FB Corruption meint FRAMEBUFFER kaputt, das sind die Strukturen im OS/Programm welche die Grafik handhaben. )

Wie man vorn sehen kann, handelt sich nicht um einen HW Fehler, sondern am wahrscheinlichsten um einen Grafikkartentreiberbug.

Ab jetzt kann man nur noch spekulieren, weil das ja alles mögliche meinen kann. Es geht sogar soweit, daß Xid 32 Probleme bei der Stromzuführung in die Grafikkarte meinen kann, also wenn das Netzteil schwächelt. Da aber der Bildschirm nicht ausgeht, hat die Graka noch genug Saft, das kann es also eigentlich nicht sein.

Jetzt können wir noch etwas ausschließen: Thermalprobleme

55 Grad sind völlig normal. Im Bild oben sind zwar die Lüfter aus, aber die funktionieren nachweislich, denn man hört sie bei der Arbeit 😉

Das Nvidia Settingstool (oben im Bild) kann man beim Gamen auf dem zweiten Monitor mitlaufen lassen und so die Anzeige im Auge behalten.

Vielleicht doch nur ein Treiberproblem?

Jetzt bringt uns das nicht weiter. Wir haben zwar 2 Sachen ausschließen können, aber es blieben immer noch FB Problem, Memoryproblem. Keins davon kann man prüfen.

Was man jetzt noch prüfen könnte, steht im /var/log/messages sofern man das noch hat. ( Habt Ihr nicht mehr, nur noch Systemd? Ihr tut mir so leid .. ehrlich 🙁 )

$ grep NVRM /var/log/messages

Jul 23 00:43:18 eve kernel: NVRM: Xid (PCI:0000:01:00): 31, pid=1923, Ch 00000020, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_PE_0 faulted @ 0x1_0ca39000. Fault is of type FAULT_PTE ACCESS_TYPE_READ

Andere Fehlernummer.. interessant. Ist ein reiner Anwendungsbug. In diesem Fall in WINE. Wine hat in den letzten Wochen unheimlich viele Updates rausgehauen. Es wäre also wirklich im Bereich des Möglichen, daß Wine bzw. der 3D Treiber in Wine ( DXVK ) hier die eigentliche Ursache sind.

Wine hat allerdings noch ganz andere Probleme, die die Entwickler aber leider nicht wahr haben wollen, weil Bugreports ignoriert werden. Ab Wine-Staging 5.5+ kommt es zu einem wahrlich irren Bug:

Es kommt in Verbindung mit dem Grakafehler zu einem IO-Fehler mit dem DVD-ROM, welches aber gar nicht benutzt wird noch eine DVD drin hat. Das sieht dann so aus:

[22163.062313] sr 1:0:0:0: [sr0] tag#26 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
[22163.062316] sr 1:0:0:0: [sr0] tag#26 Sense Key : Not Ready [current]
[22163.062319] sr 1:0:0:0: [sr0] tag#26 Add. Sense: Medium not present – tray closed
[22163.062321] sr 1:0:0:0: [sr0] tag#26 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00
[22163.062323] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 2 prio class 0
[22163.062366] sr 1:0:0:0: [sr0] tag#3 unaligned transfer
[22163.062368] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062370] Buffer I/O error on dev sr0, logical block 0, async page read
[22163.062382] sr 1:0:0:0: [sr0] tag#4 unaligned transfer
[22163.062383] blk_update_request: I/O error, dev sr0, sector 1 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062384] Buffer I/O error on dev sr0, logical block 1, async page read
[22163.062393] sr 1:0:0:0: [sr0] tag#5 unaligned transfer
[22163.062394] blk_update_request: I/O error, dev sr0, sector 2 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062395] Buffer I/O error on dev sr0, logical block 2, async page read
[22163.062404] sr 1:0:0:0: [sr0] tag#6 unaligned transfer
[22163.062405] blk_update_request: I/O error, dev sr0, sector 3 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062406] Buffer I/O error on dev sr0, logical block 3, async page read
[22163.062415] sr 1:0:0:0: [sr0] tag#7 unaligned transfer
[22163.062416] blk_update_request: I/O error, dev sr0, sector 4 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062417] Buffer I/O error on dev sr0, logical block 4, async page read
[22163.062425] sr 1:0:0:0: [sr0] tag#8 unaligned transfer
[22163.062427] blk_update_request: I/O error, dev sr0, sector 5 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062427] Buffer I/O error on dev sr0, logical block 5, async page read
[22163.062436] sr 1:0:0:0: [sr0] tag#9 unaligned transfer
[22163.062437] blk_update_request: I/O error, dev sr0, sector 6 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062438] Buffer I/O error on dev sr0, logical block 6, async page read
[22163.062446] sr 1:0:0:0: [sr0] tag#10 unaligned transfer
[22163.062448] blk_update_request: I/O error, dev sr0, sector 7 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062448] Buffer I/O error on dev sr0, logical block 7, async page read

und das ist nur beim Starten von Wine, da ist noch nicht mal eine GFX Operation gelaufen. Mit WIne 5.13 geht nicht mal ein Fenster auf, das ist derzeit komplett im *****.

Das bestärkt mich in der Annahme, daß es sich um reine Driverbugs handelt, die von WINE getriggert werden. Rein zur Vorsicht, habe ich das .nv/GLCache geleert, vielleicht lag da ja noch was defektes drin.

Mehr ist zu dem Zeitpunkt leider nicht feststellbar. Jetzt hilft nur Testen, updaten, Testen und weiter Testen.