Mittel28 / 100Konfidenz: Mittel

CVSS9.8EPSS0.3 %Über Netz erreichbarOhne AnmeldungOhne Zutun des Nutzers

Installieren Sie umgehend die verfügbaren Sicherheitsupdates für alle betroffenen Linux-Systeme und Produkte.

▸Herleitung der Bewertung(2)

Wie der Wert zustande kommt

Hoechster CVSS-Basiswert 9.8+18
Ohne Anmeldung ueber das Netz ausnutzbar (CVE-2023-53463, CVSS-Vektor AV:N/PR:N)+10

Woraus sich die Konfidenz ergibt

Nur ein Herausgeber — keine Gegenlesung
Darunter eine behoerdliche Primaerquelle
Strukturierte CVE-Daten aus der NVD vorhanden

Die Konfidenz misst die Belegqualität, nicht die Schwere.

Einschränkungen

Schmale Datenlage: der Wert beruht auf wenigen Einzelsignalen.
102 im Text genannte CVE(s) liegen uns nicht vor und gehen nicht in die Bewertung ein: CVE-2022-50421, CVE-2022-50422, CVE-2022-50423, CVE-2022-50424, CVE-2022-50425, CVE-2022-50426, CVE-2022-50427, CVE-2022-50428, CVE-2022-50429, CVE-2022-50430, CVE-2022-50431, CVE-2022-50433, CVE-2022-50434, CVE-2022-50435, CVE-2022-50436, CVE-2022-50438, CVE-2022-50439, CVE-2022-50441, CVE-2022-50443, CVE-2022-50444, CVE-2022-50445, CVE-2022-50446, CVE-2022-50447, CVE-2022-50448, CVE-2022-50449, CVE-2022-50450, CVE-2022-50452, CVE-2022-50453, CVE-2022-50455, CVE-2022-50456, CVE-2022-50457, CVE-2022-50458, CVE-2022-50460, CVE-2022-50461, CVE-2022-50462, CVE-2022-50463, CVE-2022-50464, CVE-2022-50465, CVE-2022-50466, CVE-2022-50467, CVE-2022-50468, CVE-2022-50469, CVE-2023-34319, CVE-2023-3773, CVE-2023-53448, CVE-2023-53449, CVE-2023-53450, CVE-2023-53451, CVE-2023-53452, CVE-2023-53453, CVE-2023-53455, CVE-2023-53456, CVE-2023-53457, CVE-2023-53458, CVE-2023-53459, CVE-2023-53460, CVE-2023-53461, CVE-2023-53464, CVE-2023-53466, CVE-2023-53467, CVE-2023-53468, CVE-2023-53469, CVE-2023-53470, CVE-2023-53471, CVE-2023-53472, CVE-2023-53475, CVE-2023-53476, CVE-2023-53477, CVE-2023-53479, CVE-2023-53480, CVE-2023-53482, CVE-2023-53483, CVE-2023-53487, CVE-2023-53488, CVE-2023-53489, CVE-2023-53496, CVE-2023-53497, CVE-2023-53498, CVE-2023-53501, CVE-2023-53502, CVE-2023-53503, CVE-2023-53505, CVE-2023-53507, CVE-2023-53508, CVE-2023-53509, CVE-2023-53511, CVE-2023-53512, CVE-2023-53513, CVE-2023-53514, CVE-2023-53515, CVE-2023-53516, CVE-2023-53519, CVE-2023-53521, CVE-2023-53522, CVE-2023-53523, CVE-2023-53524, CVE-2023-53525, CVE-2023-53527, CVE-2023-53528, CVE-2023-53529, CVE-2023-53530, CVE-2023-53532

Bewertung v1.1, deterministisch berechnet. Bedrohungswert und Konfidenz sind getrennte Größen.· 2026-09-07 10:54 UTCMethodik

Red Team

[UPDATE] [mittel] Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service

CERT-Bund·4. September 2026, 11:39

Originalartikel lesen bei CERT-Bund

Mehrere Schwachstellen im Linux Kernel ermöglichen Angreifern Denial-of-Service-Angriffe und weitere Effekte. Betroffen sind zahlreiche Linux-Distributionen und Produkte, darunter Amazon Linux, Debian, Dell-Produkte, IBM QRadar und Red Hat Enterprise Linux. Nutzern wird dringend empfohlen, die entsprechenden Updates für ihre Systeme und Produkte zu installieren, um diese Sicherheitslücken zu schließen.

SecBoard-Einordnung

Diese Schwachstellen können zu Denial-of-Service-Angriffen führen, welche die Verfügbarkeit kritischer Systeme und Dienste beeinträchtigen können. Dies kann Betriebsunterbrechungen und finanzielle Verluste zur Folge haben.

Realistisch schlimmster Fall: Ein erfolgreicher Denial-of-Service-Angriff führt zum Ausfall kritischer Linux-basierter Systeme und Dienste, was zu erheblichen Betriebsunterbrechungen und potenziellen Datenverlusten oder -inkonsistenzen führen kann, falls Dienste nicht ordnungsgemäß heruntergefahren werden.

Empfehlung: Installieren Sie umgehend die verfügbaren Sicherheitsupdates für alle betroffenen Linux-Systeme und Produkte. Überprüfen Sie die offiziellen Kanäle Ihrer Distributionen und Hersteller auf Patch-Verfügbarkeit.

Key Facts· 12 / 138

Nach Dringlichkeit sortiert: KEV-Eintrag, dann CVSS, dann EPSS. Vollstaendige Liste im Meldungstext.

CVE-2023-53517

CVSS: 9.8 · CRITICAL
EPSS: 0.3%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2023-53454

CVSS: 8.8 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2022-50442

CVSS: 8.4 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2023-53493

CVSS: 8.4 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2023-53485

CVSS: 7.8 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2023-53465

CVSS: 7.8 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2022-50459

CVSS: 7.8 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2022-50440

CVSS: 7.8 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2023-53492

CVSS: 7.8 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2022-50437

CVSS: 7.8 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2023-53473

CVSS: 7.8 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2023-53474

CVSS: 7.8 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

Betroffen

Organisationen, die Linux-Distributionen oder Produkte verwenden, die auf dem Linux Kernel basieren, sind betroffen. Dazu gehören Amazon Linux, Debian, Dell-Produkte, IBM QRadar und Red Hat Enterprise Linux.

Hersteller

Linux

Produkte

Linux Kernel

▸ CPE-Rohbezeichner anzeigen (1)

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*

Prüfen

▸Überprüfen Sie die Versionen Ihrer Linux-Kernel und installierten Produkte auf allen Systemen, um festzustellen, ob sie von den genannten Schwachstellen betroffen sind.
▸Stellen Sie sicher, dass Ihr Patch-Management-Prozess die schnelle Bereitstellung von Kernel-Updates für Linux-Systeme ermöglicht und priorisiert.

▸ 1 weitere

▸Überwachen Sie Systemprotokolle und Netzwerkverkehr auf Anzeichen von Denial-of-Service-Angriffen oder ungewöhnlichem Ressourcenverbrauch auf Ihren Linux-Servern.

Offene Punkte

▸ anzeigen

▸Die genauen technischen Details der Schwachstellen (z.B. CVE-IDs) sind im Artikel nicht spezifiziert.
▸Die 'weiteren Effekte' neben Denial of Service sind nicht näher beschrieben.
▸Spezifische Versionen des Linux Kernels, die betroffen sind, sind nicht genannt.

Red-Team-Relevanz

Was heißt das für dein nächstes Assessment?

▸ Einordnung anzeigen

Initial Access möglich?Ja
Privilege Escalation relevant?Unklar
Exploit öffentlich verfügbar?Möglich
Detection / Logging prüfbar?Ja
Für Purple-Team-Szenario geeignet?Möglich

Kundenfragen

Haben wir Oracle extern erreichbar?
Können wir Command & Control detektieren?

MITRE ATT&CK(2)

Techniken aus allen Quellen zusammengeführt — nach Stärke des Belegs sortiert.

T1499Denial of Servicezugeordnet

„Mehrere Schwachstellen im Linux Kernel ermöglichen Angreifern Denial-of-Service-Angriffe“

T1090Proxyabgeleitet

Mehrere Herkünfte bei derselben Technik heißt: mehrere unabhängige Wege führen dorthin.

Kill-Chain-Phasen

Wie weit im Ablauf die belegten Techniken liegen — je Technik die früheste Phase.

Auskundschaften

›

Bewaffnung

›

Zustellung

›

Ausnutzung

›

Einnistung

›

Fernsteuerung

›

Zielhandlung

Quellen & Belege· 1 Quelle

CERT-BundPrimärbelegPUBLICZuverlässigkeit Adiese Meldung

Behoerdliche Veroeffentlichung mit Amtspflicht zur Richtigkeit, frei zugaenglich.

Nur eine Quelle — der Sachverhalt ist an keiner zweiten Stelle gegengelesen.

Verknüpfte Intelligence

Dieselben Entitäten an anderer Stelle auf SecBoard.

Themen

mittel

Vollständigen Artikel lesen bei CERT-Bund

Erwähnte CVEs (12)

CVE-2023-53517CRITICAL(9.8)

EPSS 0.3%

In the Linux kernel, the following vulnerability has been resolved: tipc: do not update mtu if msg_max is too small in mtu negotiation When doing link mtu negotiation, a malicious peer may send Activate msg with a very small mtu, e.g. 4 in Shuang's testing, without checking for the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then n->links[bearer_id].mtu is set to 4294967228, which is a overflow of '4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss(). With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning: tipc: Too large msg, purging xmit list 1 5 0 40 4! tipc: Too large msg, purging xmit list 1 15 0 60 4! And with tipc_link_entry.mtu 4294967228, a huge skb was allocated in named_distribute(), and when purging it in tipc_link_xmit(), a crash was even caused: general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19 RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0 Call Trace: <IRQ> skb_release_data+0xf9/0x1d0 kfree_skb_reason+0x40/0x100 tipc_link_xmit+0x57a/0x740 [tipc] tipc_node_xmit+0x16c/0x5c0 [tipc] tipc_named_node_up+0x27f/0x2c0 [tipc] tipc_node_write_unlock+0x149/0x170 [tipc] tipc_rcv+0x608/0x740 [tipc] tipc_udp_recv+0xdc/0x1f0 [tipc] udp_queue_rcv_one_skb+0x33e/0x620 udp_unicast_rcv_skb.isra.72+0x75/0x90 __udp4_lib_rcv+0x56d/0xc20 ip_protocol_deliver_rcu+0x100/0x2d0 This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(), and not updating mtu if it is too small.

Details NVD

CVE-2023-53454HIGH(8.8)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Correct devm device reference for hidinput input_dev name Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management. Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string.

Details NVD

CVE-2022-50442HIGH(8.4)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Validate buffer length while parsing index indx_read is called when we have some NTFS directory operations that need more information from the index buffers. This adds a sanity check to make sure the returned index buffer length is legit, or we may have some out-of-bound memory accesses. [ 560.897595] BUG: KASAN: slab-out-of-bounds in hdr_find_e.isra.0+0x10c/0x320 [ 560.898321] Read of size 2 at addr ffff888009497238 by task exp/245 [ 560.898760] [ 560.899129] CPU: 0 PID: 245 Comm: exp Not tainted 6.0.0-rc6 #37 [ 560.899505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 560.900170] Call Trace: [ 560.900407] <TASK> [ 560.900732] dump_stack_lvl+0x49/0x63 [ 560.901108] print_report.cold+0xf5/0x689 [ 560.901395] ? hdr_find_e.isra.0+0x10c/0x320 [ 560.901716] kasan_report+0xa7/0x130 [ 560.901950] ? hdr_find_e.isra.0+0x10c/0x320 [ 560.902208] __asan_load2+0x68/0x90 [ 560.902427] hdr_find_e.isra.0+0x10c/0x320 [ 560.902846] ? cmp_uints+0xe0/0xe0 [ 560.903363] ? cmp_sdh+0x90/0x90 [ 560.903883] ? ntfs_bread_run+0x190/0x190 [ 560.904196] ? rwsem_down_read_slowpath+0x750/0x750 [ 560.904969] ? ntfs_fix_post_read+0xe0/0x130 [ 560.905259] ? __kasan_check_write+0x14/0x20 [ 560.905599] ? up_read+0x1a/0x90 [ 560.905853] ? indx_read+0x22c/0x380 [ 560.906096] indx_find+0x2ef/0x470 [ 560.906352] ? indx_find_buffer+0x2d0/0x2d0 [ 560.906692] ? __kasan_kmalloc+0x88/0xb0 [ 560.906977] dir_search_u+0x196/0x2f0 [ 560.907220] ? ntfs_nls_to_utf16+0x450/0x450 [ 560.907464] ? __kasan_check_write+0x14/0x20 [ 560.907747] ? mutex_lock+0x8f/0xe0 [ 560.907970] ? __mutex_lock_slowpath+0x20/0x20 [ 560.908214] ? kmem_cache_alloc+0x143/0x4b0 [ 560.908459] ntfs_lookup+0xe0/0x100 [ 560.908788] __lookup_slow+0x116/0x220 [ 560.909050] ? lookup_fast+0x1b0/0x1b0 [ 560.909309] ? lookup_fast+0x13f/0x1b0 [ 560.909601] walk_component+0x187/0x230 [ 560.909944] link_path_walk.part.0+0x3f0/0x660 [ 560.910285] ? handle_lookup_down+0x90/0x90 [ 560.910618] ? path_init+0x642/0x6e0 [ 560.911084] ? percpu_counter_add_batch+0x6e/0xf0 [ 560.912559] ? __alloc_file+0x114/0x170 [ 560.913008] path_openat+0x19c/0x1d10 [ 560.913419] ? getname_flags+0x73/0x2b0 [ 560.913815] ? kasan_save_stack+0x3a/0x50 [ 560.914125] ? kasan_save_stack+0x26/0x50 [ 560.914542] ? __kasan_slab_alloc+0x6d/0x90 [ 560.914924] ? kmem_cache_alloc+0x143/0x4b0 [ 560.915339] ? getname_flags+0x73/0x2b0 [ 560.915647] ? getname+0x12/0x20 [ 560.916114] ? __x64_sys_open+0x4c/0x60 [ 560.916460] ? path_lookupat.isra.0+0x230/0x230 [ 560.916867] ? __isolate_free_page+0x2e0/0x2e0 [ 560.917194] do_filp_open+0x15c/0x1f0 [ 560.917448] ? may_open_dev+0x60/0x60 [ 560.917696] ? expand_files+0xa4/0x3a0 [ 560.917923] ? __kasan_check_write+0x14/0x20 [ 560.918185] ? _raw_spin_lock+0x88/0xdb [ 560.918409] ? _raw_spin_lock_irqsave+0x100/0x100 [ 560.918783] ? _find_next_bit+0x4a/0x130 [ 560.919026] ? _raw_spin_unlock+0x19/0x40 [ 560.919276] ? alloc_fd+0x14b/0x2d0 [ 560.919635] do_sys_openat2+0x32a/0x4b0 [ 560.920035] ? file_open_root+0x230/0x230 [ 560.920336] ? __rcu_read_unlock+0x5b/0x280 [ 560.920813] do_sys_open+0x99/0xf0 [ 560.921208] ? filp_open+0x60/0x60 [ 560.921482] ? exit_to_user_mode_prepare+0x49/0x180 [ 560.921867] __x64_sys_open+0x4c/0x60 [ 560.922128] do_syscall_64+0x3b/0x90 [ 560.922369] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 560.923030] RIP: 0033:0x7f7dff2e4469 [ 560.923681] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088 [ 560.924451] RSP: 002b:00007ffd41a210b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000002 [ 560.925168] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7dff2e4469 [ 560.925655] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ---truncated---

Details NVD

CVE-2023-53493HIGH(8.4)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: accel/qaic: tighten bounds checking in decode_message() Copy the bounds checking from encode_message() to decode_message(). This patch addresses the following concerns. Ensure that there is enough space for at least one header so that we don't have a negative size later. if (msg_hdr_len < sizeof(*trans_hdr)) Ensure that we have enough space to read the next header from the msg->data. if (msg_len > msg_hdr_len - sizeof(*trans_hdr)) return -EINVAL; Check that the trans_hdr->len is not below the minimum size: if (hdr_len < sizeof(*trans_hdr)) This minimum check ensures that we don't corrupt memory in decode_passthrough() when we do. memcpy(out_trans->data, in_trans->data, len - sizeof(in_trans->hdr)); And finally, use size_add() to prevent an integer overflow: if (size_add(msg_len, hdr_len) > msg_hdr_len)

Details NVD

CVE-2023-53485HIGH(7.8)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: fs: jfs: Fix UBSAN: array-index-out-of-bounds in dbAllocDmapLev Syzkaller reported the following issue: UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:1965:6 index -84 is out of range for type 's8[341]' (aka 'signed char[341]') CPU: 1 PID: 4995 Comm: syz-executor146 Not tainted 6.4.0-rc6-syzkaller-00037-gb6dad5178cea #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline] __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 dbAllocDmapLev+0x3e5/0x430 fs/jfs/jfs_dmap.c:1965 dbAllocCtl+0x113/0x920 fs/jfs/jfs_dmap.c:1809 dbAllocAG+0x28f/0x10b0 fs/jfs/jfs_dmap.c:1350 dbAlloc+0x658/0xca0 fs/jfs/jfs_dmap.c:874 dtSplitUp fs/jfs/jfs_dtree.c:974 [inline] dtInsert+0xda7/0x6b00 fs/jfs/jfs_dtree.c:863 jfs_create+0x7b6/0xbb0 fs/jfs/namei.c:137 lookup_open fs/namei.c:3492 [inline] open_last_lookups fs/namei.c:3560 [inline] path_openat+0x13df/0x3170 fs/namei.c:3788 do_filp_open+0x234/0x490 fs/namei.c:3818 do_sys_openat2+0x13f/0x500 fs/open.c:1356 do_sys_open fs/open.c:1372 [inline] __do_sys_openat fs/open.c:1388 [inline] __se_sys_openat fs/open.c:1383 [inline] __x64_sys_openat+0x247/0x290 fs/open.c:1383 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f1f4e33f7e9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc21129578 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1f4e33f7e9 RDX: 000000000000275a RSI: 0000000020000040 RDI: 00000000ffffff9c RBP: 00007f1f4e2ff080 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f1f4e2ff110 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> The bug occurs when the dbAllocDmapLev()function attempts to access dp->tree.stree[leafidx + LEAFIND] while the leafidx value is negative. To rectify this, the patch introduces a safeguard within the dbAllocDmapLev() function. A check has been added to verify if leafidx is negative. If it is, the function immediately returns an I/O error, preventing any further execution that could potentially cause harm. Tested via syzbot.

Details NVD

CVE-2023-53465HIGH(7.8)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: soundwire: qcom: fix storing port config out-of-bounds The 'qcom_swrm_ctrl->pconfig' has size of QCOM_SDW_MAX_PORTS (14), however we index it starting from 1, not 0, to match real port numbers. This can lead to writing port config past 'pconfig' bounds and overwriting next member of 'qcom_swrm_ctrl' struct. Reported also by smatch: drivers/soundwire/qcom.c:1269 qcom_swrm_get_port_config() error: buffer overflow 'ctrl->pconfig' 14 <= 14

Details NVD

CVE-2022-50459HIGH(7.8)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername() Fix a NULL pointer crash that occurs when we are freeing the socket at the same time we access it via sysfs. The problem is that: 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold() does a get on the "struct sock". 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put on the "struct socket" and that does __sock_release() which sets the sock->ops to NULL. 3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then call kernel_getpeername() which accesses the NULL sock->ops. Above we do a get on the "struct sock", but we needed a get on the "struct socket". Originally, we just held the frwd_lock the entire time but in commit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock while calling getpeername()") we switched to refcount based because the network layer changed and started taking a mutex in that path, so we could no longer hold the frwd_lock. Instead of trying to maintain multiple refcounts, this just has us use a mutex for accessing the socket in the interface code paths.

Details NVD

CVE-2022-50440HIGH(7.8)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate the box size for the snooped cursor Invalid userspace dma surface copies could potentially overflow the memcpy from the surface to the snooped image leading to crashes. To fix it the dimensions of the copybox have to be validated against the expected size of the snooped cursor.

Details NVD

CVE-2023-53492HIGH(7.8)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not ignore genmask when looking up chain by id When adding a rule to a chain referring to its ID, if that chain had been deleted on the same batch, the rule might end up referring to a deleted chain. This will lead to a WARNING like following: [ 33.098431] ------------[ cut here ]------------ [ 33.098678] WARNING: CPU: 5 PID: 69 at net/netfilter/nf_tables_api.c:2037 nf_tables_chain_destroy+0x23d/0x260 [ 33.099217] Modules linked in: [ 33.099388] CPU: 5 PID: 69 Comm: kworker/5:1 Not tainted 6.4.0+ #409 [ 33.099726] Workqueue: events nf_tables_trans_destroy_work [ 33.100018] RIP: 0010:nf_tables_chain_destroy+0x23d/0x260 [ 33.100306] Code: 8b 7c 24 68 e8 64 9c ed fe 4c 89 e7 e8 5c 9c ed fe 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7 c3 cc cc cc cc <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7 [ 33.101271] RSP: 0018:ffffc900004ffc48 EFLAGS: 00010202 [ 33.101546] RAX: 0000000000000001 RBX: ffff888006fc0a28 RCX: 0000000000000000 [ 33.101920] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 33.102649] RBP: ffffc900004ffc78 R08: 0000000000000000 R09: 0000000000000000 [ 33.103018] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880135ef500 [ 33.103385] R13: 0000000000000000 R14: dead000000000122 R15: ffff888006fc0a10 [ 33.103762] FS: 0000000000000000(0000) GS:ffff888024c80000(0000) knlGS:0000000000000000 [ 33.104184] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 33.104493] CR2: 00007fe863b56a50 CR3: 00000000124b0001 CR4: 0000000000770ee0 [ 33.104872] PKRU: 55555554 [ 33.104999] Call Trace: [ 33.105113] <TASK> [ 33.105214] ? show_regs+0x72/0x90 [ 33.105371] ? __warn+0xa5/0x210 [ 33.105520] ? nf_tables_chain_destroy+0x23d/0x260 [ 33.105732] ? report_bug+0x1f2/0x200 [ 33.105902] ? handle_bug+0x46/0x90 [ 33.106546] ? exc_invalid_op+0x19/0x50 [ 33.106762] ? asm_exc_invalid_op+0x1b/0x20 [ 33.106995] ? nf_tables_chain_destroy+0x23d/0x260 [ 33.107249] ? nf_tables_chain_destroy+0x30/0x260 [ 33.107506] nf_tables_trans_destroy_work+0x669/0x680 [ 33.107782] ? mark_held_locks+0x28/0xa0 [ 33.107996] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [ 33.108294] ? _raw_spin_unlock_irq+0x28/0x70 [ 33.108538] process_one_work+0x68c/0xb70 [ 33.108755] ? lock_acquire+0x17f/0x420 [ 33.108977] ? __pfx_process_one_work+0x10/0x10 [ 33.109218] ? do_raw_spin_lock+0x128/0x1d0 [ 33.109435] ? _raw_spin_lock_irq+0x71/0x80 [ 33.109634] worker_thread+0x2bd/0x700 [ 33.109817] ? __pfx_worker_thread+0x10/0x10 [ 33.110254] kthread+0x18b/0x1d0 [ 33.110410] ? __pfx_kthread+0x10/0x10 [ 33.110581] ret_from_fork+0x29/0x50 [ 33.110757] </TASK> [ 33.110866] irq event stamp: 1651 [ 33.111017] hardirqs last enabled at (1659): [<ffffffffa206a209>] __up_console_sem+0x79/0xa0 [ 33.111379] hardirqs last disabled at (1666): [<ffffffffa206a1ee>] __up_console_sem+0x5e/0xa0 [ 33.111740] softirqs last enabled at (1616): [<ffffffffa1f5d40e>] __irq_exit_rcu+0x9e/0xe0 [ 33.112094] softirqs last disabled at (1367): [<ffffffffa1f5d40e>] __irq_exit_rcu+0x9e/0xe0 [ 33.112453] ---[ end trace 0000000000000000 ]--- This is due to the nft_chain_lookup_byid ignoring the genmask. After this change, adding the new rule will fail as it will not find the chain.

Details NVD

CVE-2022-50437HIGH(7.8)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502670/

Details NVD

CVE-2023-53473HIGH(7.8)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: ext4: improve error handling from ext4_dirhash() The ext4_dirhash() will *almost* never fail, especially when the hash tree feature was first introduced. However, with the addition of support of encrypted, casefolded file names, that function can most certainly fail today. So make sure the callers of ext4_dirhash() properly check for failures, and reflect the errors back up to their callers.

Details NVD

CVE-2023-53474HIGH(7.8)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: x86/MCE/AMD: Use an u64 for bank_map Thee maximum number of MCA banks is 64 (MAX_NR_BANKS), see a0bc32b3cacf ("x86/mce: Increase maximum number of banks to 64"). However, the bank_map which contains a bitfield of which banks to initialize is of type unsigned int and that overflows when those bit numbers are >= 32, leading to UBSAN complaining correctly: UBSAN: shift-out-of-bounds in arch/x86/kernel/cpu/mce/amd.c:1365:38 shift exponent 32 is too large for 32-bit type 'int' Change the bank_map to a u64 and use the proper BIT_ULL() macro when modifying bits in there. [ bp: Rewrite commit message. ]

Details NVD