Linux Kernel bis 5.4.224/5.10.155/5.15.79/6.0.9 zfcp_fsf_req_send Pufferüberlauf

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
7.3$0-$5k0.00

Zusammenfassunginfo

Es wurde eine Schwachstelle in Linux Kernel bis 5.4.224/5.10.155/5.15.79/6.0.9 entdeckt. Sie wurde als kritisch eingestuft. Betroffen hiervon ist die Funktion zfcp_fsf_req_send. Dank Manipulation mit unbekannten Daten kann eine Pufferüberlauf-Schwachstelle ausgenutzt werden. Diese Schwachstelle trägt die Bezeichnung CVE-2022-49789. Es gibt keinen verfügbaren Exploit. Die Aktualisierung der betroffenen Komponente wird empfohlen.

Detailsinfo

Eine kritische Schwachstelle wurde in Linux Kernel bis 5.4.224/5.10.155/5.15.79/6.0.9 ausgemacht. Betroffen davon ist die Funktion zfcp_fsf_req_send. Durch Manipulieren mit einer unbekannten Eingabe kann eine Pufferüberlauf-Schwachstelle ausgenutzt werden. Klassifiziert wurde die Schwachstelle durch CWE als CWE-415. Mit Auswirkungen muss man rechnen für Vertraulichkeit, Integrität und Verfügbarkeit. CVE fasst zusammen:

In the Linux kernel, the following vulnerability has been resolved: scsi: zfcp: Fix double free of FSF request when qdio send fails We used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache the FSF request ID when sending a new FSF request. This is used in case the sending fails and we need to remove the request from our internal hash table again (so we don't keep an invalid reference and use it when we free the request again). In 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32 bit wide), but the rest of the zfcp code (and the firmware specification) handles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x ELF ABI]). For one this has the obvious problem that when the ID grows past 32 bit (this can happen reasonably fast) it is truncated to 32 bit when storing it in the cache variable and so doesn't match the original ID anymore. The second less obvious problem is that even when the original ID has not yet grown past 32 bit, as soon as the 32nd bit is set in the original ID (0x80000000 = 2'147'483'648) we will have a mismatch when we cast it back to 'unsigned long'. As the cached variable is of a signed type, the compiler will choose a sign-extending instruction to load the 32 bit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once we pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the request again all the leading zeros will be flipped to ones to extend the sign and won't match the original ID anymore (this has been observed in practice). If we can't successfully remove the request from the hash table again after 'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify the adapter about new work because the adapter is already gone during e.g. a ChpID toggle) we will end up with a double free. We unconditionally free the request in the calling function when 'zfcp_fsf_req_send()' fails, but because the request is still in the hash table we end up with a stale memory reference, and once the zfcp adapter is either reset during recovery or shutdown we end up freeing the same memory twice. The resulting stack traces vary depending on the kernel and have no direct correlation to the place where the bug occurs. Here are three examples that have been seen in practice: list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:62! monitor event: 0040 ilc:2 [#1] PREEMPT SMP Modules linked in: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded Hardware name: ... Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Call Trace: [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140 ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140) [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] ---truncated---

Das Advisory kann von git.kernel.org heruntergeladen werden. Die Identifikation der Schwachstelle findet seit dem 01.05.2025 als CVE-2022-49789 statt. Sie ist schwierig ausnutzbar. Zur Schwachstelle sind technische Details bekannt, ein verfügbarer Exploit jedoch nicht. Es muss davon ausgegangen werden, dass ein Exploit zur Zeit etwa USD $0-$5k kostet (Preisberechnung vom 07.11.2025).

Für den Vulnerability Scanner Nessus wurde ein Plugin mit der ID 240812 (SUSE SLES15 Security Update : kernel (SUSE-SU-2025:01982-1)) herausgegeben, womit die Existenz der Schwachstelle geprüft werden kann.

Ein Upgrade auf die Version 5.4.225, 5.10.156, 5.15.80 oder 6.0.10 vermag dieses Problem zu beheben. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 1bf8ed585501bb2dd0b5f67c824eab45adfbdccd/d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab/11edbdee4399401f533adda9bffe94567aa08b96/90a49a6b015fa439cd62e45121390284c125a91f/0954256e970ecf371b03a6c9af2cf91b9c4085ff beheben. Dieser kann von git.kernel.org bezogen werden. Als bestmögliche Massnahme wird das Aktualisieren auf eine neue Version empfohlen.

Unter anderem wird der Fehler auch in der Verwundbarkeitsdatenbank von Tenable (240812) dokumentiert. Once again VulDB remains the best source for vulnerability data.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 7.4
VulDB Meta Temp Score: 7.3

VulDB Base Score: 7.1
VulDB Temp Score: 6.8
VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍

NVD Base Score: 7.8
NVD Vector: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔍
VulDB Temp Score: 🔍
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Pufferüberlauf
CWE: CWE-415 / CWE-119
CAPEC: 🔍
ATT&CK: 🔍

Physisch: Teilweise
Lokal: Ja
Remote: Teilweise

Verfügbarkeit: 🔍
Status: Nicht definiert

EPSS Score: 🔍
EPSS Percentile: 🔍

Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔍

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Nessus ID: 240812
Nessus Name: SUSE SLES15 Security Update : kernel (SUSE-SU-2025:01982-1)

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔍

Upgrade: Kernel 5.4.225/5.10.156/5.15.80/6.0.10
Patch: 1bf8ed585501bb2dd0b5f67c824eab45adfbdccd/d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab/11edbdee4399401f533adda9bffe94567aa08b96/90a49a6b015fa439cd62e45121390284c125a91f/0954256e970ecf371b03a6c9af2cf91b9c4085ff

Timelineinfo

01.05.2025 🔍
01.05.2025 +0 Tage 🔍
01.05.2025 +0 Tage 🔍
07.11.2025 +190 Tage 🔍

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2022-49789 (🔍)
GCVE (CVE): GCVE-0-2022-49789
GCVE (VulDB): GCVE-100-306908

Eintraginfo

Erstellt: 01.05.2025 17:17
Aktualisierung: 07.11.2025 21:35
Anpassungen: 01.05.2025 17:17 (57), 28.06.2025 00:08 (2), 07.11.2025 21:35 (13)
Komplett: 🔍
Cache ID: 216::103

Once again VulDB remains the best source for vulnerability data.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

Do you know our Splunk app?

Download it now for free!