Kwetsbaarheden worden geladen…
Kwetsbaarheden worden geladen…
CVE-2026-23414
In the Linux kernel, the following vulnerability has been resolved: tls: Purge async_hold in tls_decrypt_async_wait() The async_hold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. Once tls_decrypt_async_wait() returns, every AEAD operation has completed and the engine no longer references those skbs, so they can be freed unconditionally. A subsequent patch adds batch async decryption to tls_sw_read_sock(), introducing a new call site that must drain pending AEAD operations and release held skbs. Move __skb_queue_purge(&ctx->async_hold) into tls_decrypt_async_wait() so the purge is centralized and every caller -- recvmsg's drain path, the -EBUSY fallback in tls_do_decryption(), and the new read_sock batch path -- releases held skbs on synchronization without each site managing the purge independently. This fixes a leak when tls_strp_msg_hold() fails part-way through, after having added some cloned skbs to the async_hold queue. tls_decrypt_sg() will then call tls_decrypt_async_wait() to process all pending decrypts, and drop back to synchronous mode, but tls_sw_recvmsg() only flushes the async_hold queue when one record has been processed in "fully-async" mode, which may not be the case here. [pabeni@redhat.com: added leak comment]
Dit record: live koppeling— laatst opgehaald: 24 september 2026 om 04:16.
Rechtstreeks overgenomen uit NVD, CISA of de leverancier — soms Engelstalig, ongewijzigd t.o.v. de bron.
In the Linux kernel, the following vulnerability has been resolved: tls: Purge async_hold in tls_decrypt_async_wait() The async_hold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. Once tls_decrypt_async_wait() returns, every AEAD operation has completed and the engine no longer references those skbs, so they can be freed unconditionally. A subsequent patch adds batch async decryption to tls_sw_read_sock(), introducing a new call site that must drain pending AEAD operations and release held skbs. Move __skb_queue_purge(&ctx->async_hold) into tls_decrypt_async_wait() so the purge is centralized and every caller -- recvmsg's drain path, the -EBUSY fallback in tls_do_decryption(), and the new read_sock batch path -- releases held skbs on synchronization without each site managing the purge independently. This fixes a leak when tls_strp_msg_hold() fails part-way through, after having added some cloned skbs to the async_hold queue. tls_decrypt_sg() will then call tls_decrypt_async_wait() to process all pending decrypts, and drop back to synchronous mode, but tls_sw_recvmsg() only flushes the async_hold queue when one record has been processed in "fully-async" mode, which may not be the case here. [pabeni@redhat.com: added leak comment]
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Attack vector
NETWORK
Privileges required
NONE
User interaction
NONE
Vertrouwelijkheid
Geen
Integriteit
Geen
Beschikbaarheid
Hoog
Kans op misbruik binnen 30 dagen
0.2%
Percentiel
16e
Bron: FIRST.org, bijgewerkt op 23 september 2026.
Limit access to the interactive shell of the additional GNU/Linux subssytem to trusted personnel only.
Onze eigen Nederlandstalige interpretatie en context bij de brondata hierboven.
IACS Radar-duiding
Onze eigen interpretatie en context bij deze kwetsbaarheid — geen officiële bron.
IACS Radar-prioriteringsscore
Gebaseerd op CVSS 7.5, EPSS 0.2%, industriële relevantie 55/100.
Weegt CVSS, EPSS, KEV-status, industriële relevantie en exposure-relevantie samen — een aanvulling op, geen vervanging van, de losse scores hieronder en hierboven.
Voorwaarden voor misbruik
Operationele impact & energierelevantie
Mogelijk verlies van zicht op of besturing over het proces bij succesvol misbruik.
Beoordeeld als relevant voor de energiesector op basis van: Vermeld in een officiële CISA ICS Advisory, wat directe relevantie voor industriële besturingssystemen bevestigt. Leverancier "Siemens" is een bekende leverancier van apparatuur voor de energiesector.
Aanbevolen defensieve maatregelen
Industriële relevantiescore
Classificatie is voorlopig; handmatige verificatie door een OT-securityanalist wordt aanbevolen.
Geclassificeerd door IACS Radar-analysepijplijn (geautomatiseerd) op 24 september 2026.
IEC 62443-mapping
Automatische IACS Radar-duiding op basis van de gerapporteerde CWE-zwakteclassificatie; geen officiële certificeringsuitspraak.