Linux Kernel bis 7.1.4 xprtrdma rpcrdma_reply_handler Pufferüberlauf

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
9.5$5k-$25k0.00+

Zusammenfassunginfo

Es wurde eine Schwachstelle mit der Einstufung sehr kritisch in Linux Kernel bis 6.1.177/6.6.144/6.12.96/6.18.39/7.1.4 gefunden. Betroffen davon ist die Funktion rpcrdma_reply_handler der Komponente xprtrdma. Dank Manipulation mit unbekannten Daten kann eine Pufferüberlauf-Schwachstelle ausgenutzt werden. Diese Schwachstelle trägt die Bezeichnung CVE-2026-72473. Umgesetzt werden kann der Angriff über das Netzwerk. Es gibt keinen verfügbaren Exploit.

Detailsinfo

In Linux Kernel bis 6.1.177/6.6.144/6.12.96/6.18.39/7.1.4 wurde eine Schwachstelle ausgemacht. Sie wurde als sehr kritisch eingestuft. Dabei geht es um die Funktion rpcrdma_reply_handler der Komponente xprtrdma. Durch das Beeinflussen mit einer unbekannten Eingabe kann eine Pufferüberlauf-Schwachstelle ausgenutzt werden. CWE definiert das Problem als CWE-416. Das hat Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. CVE fasst zusammen:

In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.

Das Advisory kann von git.kernel.org heruntergeladen werden. Eine eindeutige Identifikation der Schwachstelle wird seit dem 09.08.2026 mit CVE-2026-72473 vorgenommen. Sie gilt als leicht auszunutzen. Die Umsetzung des Angriffs kann dabei über das Netzwerk erfolgen. Um eine Ausnutzung durchzusetzen, muss keine spezifische Authentisierung umgesetzt werden. Technische Details sind bekannt, ein verfügbarer Exploit hingegen nicht. Es muss davon ausgegangen werden, dass ein Exploit zur Zeit etwa USD $5k-$25k kostet (Preisberechnung vom 15.08.2026).

Ein Upgrade auf die Version 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5 oder 7.2-rc1 vermag dieses Problem zu beheben. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 740975054a1970c0cf15f70ac39724a064f45847/9f3d9b68c1c6c51746e5ecdb52b2e6a2901de37e/e7632089523acddcdd8f090ad19e96fb3107b04d/53442c7d0c888e51b8bc3da196970a669cc6b294/8203f760a72bd39a3b66bc4eff0aa272a99fe22b/e786233d2e0bbff9a82e43f02ae3a46ab4b08ec3 beheben.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 10.0
VulDB Meta Temp Score: 9.5

VulDB Base Score: 10.0
VulDB Temp Score: 9.5
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv2info

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

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

Exploitinginfo

Klasse: Pufferüberlauf
CWE: CWE-416 / CWE-119
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Nein
Lokal: Nein
Remote: Ja

Verfügbarkeit: 🔒
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

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

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 6.1.178/6.6.145/6.12.97/6.18.40/7.1.5/7.2-rc1
Patch: 740975054a1970c0cf15f70ac39724a064f45847/9f3d9b68c1c6c51746e5ecdb52b2e6a2901de37e/e7632089523acddcdd8f090ad19e96fb3107b04d/53442c7d0c888e51b8bc3da196970a669cc6b294/8203f760a72bd39a3b66bc4eff0aa272a99fe22b/e786233d2e0bbff9a82e43f02ae3a46ab4b08ec3

Timelineinfo

09.08.2026 CVE zugewiesen
15.08.2026 +6 Tage Advisory veröffentlicht
15.08.2026 +0 Tage VulDB Eintrag erstellt
15.08.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

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

CVE: CVE-2026-72473 (🔒)
GCVE (CVE): GCVE-0-2026-72473
GCVE (VulDB): GCVE-100-391048

Eintraginfo

Erstellt: 15.08.2026 17:16
Anpassungen: 15.08.2026 17:16 (59)
Komplett: 🔍
Cache ID: 216::103

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

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

Might our Artificial Intelligence support you?

Check our Alexa App!