https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 14:57:57 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-10805 bdu:2025-10805 https://cve.radiocsirt.org/vuln/bdu:2025-10805 https://cve.radiocsirt.org/vuln/bell-cve-2025-38488 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2025-38488 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0698 certfr-2025-avi-0698 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0698 https://cve.radiocsirt.org/vuln/euvd-2026-347067 EUVD-2026-347067 https://cve.radiocsirt.org/vuln/euvd-2026-347067 https://cve.radiocsirt.org/vuln/fkie_cve-2025-38488 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>smb: client: fix use-after-free in crypt_message when using async crypto</p> <p>The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:</p> <p>crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &amp;req);</p> <p>// Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);</p> <p>// Free creq while async operation is still in progress kvfree_sensitive(creq, ...);</p> <p>Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.</p> <p>This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.</p> <p>The issue occurs because crypto_alloc_aead() with mask=0 doesn&#39;t guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected.</p> <p>Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callb…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>smb: client: fix use-after-free in crypt_message when using async crypto</p> <p>The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:</p> <p>crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &amp;req);</p> <p>// Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);</p> <p>// Free creq while async operation is still in progress kvfree_sensitive(creq, ...);</p> <p>Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.</p> <p>This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.</p> <p>The issue occurs because crypto_alloc_aead() with mask=0 doesn&#39;t guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected.</p> <p>Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callb…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-38488 https://cve.radiocsirt.org/vuln/ghsa-8gh3-6693-hwj4 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>smb: client: fix use-after-free in crypt_message when using async crypto</p> <p>The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:</p> <p>crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &amp;req);</p> <p>// Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);</p> <p>// Free creq while async operation is still in progress kvfree_sensitive(creq, ...);</p> <p>Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.</p> <p>This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.</p> <p>The issue occurs because crypto_alloc_aead() with mask=0 doesn&#39;t guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected.</p> <p>Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callb…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>smb: client: fix use-after-free in crypt_message when using async crypto</p> <p>The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:</p> <p>crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &amp;req);</p> <p>// Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);</p> <p>// Free creq while async operation is still in progress kvfree_sensitive(creq, ...);</p> <p>Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.</p> <p>This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.</p> <p>The issue occurs because crypto_alloc_aead() with mask=0 doesn&#39;t guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected.</p> <p>Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callb…</p> https://cve.radiocsirt.org/vuln/ghsa-8gh3-6693-hwj4 https://cve.radiocsirt.org/vuln/msrc_cve-2025-38488 msrc_CVE-2025-38488 https://cve.radiocsirt.org/vuln/msrc_cve-2025-38488 https://cve.radiocsirt.org/vuln/oesa-2026-2416 <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>smb: client: fix use-after-free in crypt_message when using async crypto</p> <p>The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:</p> <p>crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &amp;amp;req);</p> <p>// Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);</p> <p>// Free creq while async operation is still in progress kvfree_sensitive(creq, ...);</p> <p>Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.</p> <p>This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.</p> <p>The issue occurs because crypto_alloc_aead() with mask=0 doesn&amp;apos;t guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected.</p> <p>Fix by restoring the async crypto han…</p> <p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>smb: client: fix use-after-free in crypt_message when using async crypto</p> <p>The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:</p> <p>crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &amp;amp;req);</p> <p>// Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);</p> <p>// Free creq while async operation is still in progress kvfree_sensitive(creq, ...);</p> <p>Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.</p> <p>This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.</p> <p>The issue occurs because crypto_alloc_aead() with mask=0 doesn&amp;apos;t guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected.</p> <p>Fix by restoring the async crypto han…</p> https://cve.radiocsirt.org/vuln/oesa-2026-2416 https://cve.radiocsirt.org/vuln/opensuse-su-2025:20081-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/opensuse-su-2025:20081-1 https://cve.radiocsirt.org/vuln/suse-su-2025:03600-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2025:03600-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38488 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 179 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in crypt_message when using async crypto The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes: crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &amp;req); // Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); // Free creq while async operation is still in progress kvfree_sensitive(creq, ...); Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory. This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences. The issue occurs because crypto_alloc_aead() with mask=0 doesn&#39;t guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected. Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callback() for…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 179 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in crypt_message when using async crypto The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes: crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &amp;req); // Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); // Free creq while async operation is still in progress kvfree_sensitive(creq, ...); Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory. This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences. The issue occurs because crypto_alloc_aead() with mask=0 doesn&#39;t guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected. Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callback() for…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38488 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1665 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht spezifizierte Angriffe durchzuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht spezifizierte Angriffe durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1665