https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 22:40:07 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-80835 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-80835 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1253 certfr-2026-avi-1253 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1253 https://cve.radiocsirt.org/vuln/euvd-2026-363858 EUVD-2026-363858 https://cve.radiocsirt.org/vuln/euvd-2026-363858 https://cve.radiocsirt.org/vuln/fkie_cve-2026-80835 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>crypto: qcom-rng - Remove crypto_rng interface</p> <p>qcom-rng.c exposes the same hardware through two completely separate interfaces, crypto_rng and hwrng. However, the implementation of this is buggy because it permits generation operations from these interfaces to run concurrently with each other, accessing the same registers. That is, qcom_rng_generate() synchronizes with itself but not with qcom_hwrng_read(). This results in potential repetition of output from the RNG, output of non-random values, etc.</p> <p>Fortunately, there&#39;s actually no point in hardware RNG drivers implementing the crypto_rng interface. It&#39;s not actually used by anything besides the &#34;rng&#34; algorithm type of AF_ALG, which in turn is not actually used in practice. Other crypto_rng hardware drivers are likewise being phased out, leaving just the hwrng support.</p> <p>Thus, remove it to simplify the code and avoid conflict (and confusion) with the hwrng interface which is the one that actually matters.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>crypto: qcom-rng - Remove crypto_rng interface</p> <p>qcom-rng.c exposes the same hardware through two completely separate interfaces, crypto_rng and hwrng. However, the implementation of this is buggy because it permits generation operations from these interfaces to run concurrently with each other, accessing the same registers. That is, qcom_rng_generate() synchronizes with itself but not with qcom_hwrng_read(). This results in potential repetition of output from the RNG, output of non-random values, etc.</p> <p>Fortunately, there&#39;s actually no point in hardware RNG drivers implementing the crypto_rng interface. It&#39;s not actually used by anything besides the &#34;rng&#34; algorithm type of AF_ALG, which in turn is not actually used in practice. Other crypto_rng hardware drivers are likewise being phased out, leaving just the hwrng support.</p> <p>Thus, remove it to simplify the code and avoid conflict (and confusion) with the hwrng interface which is the one that actually matters.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-80835 https://cve.radiocsirt.org/vuln/ghsa-p9vr-23cc-fh67 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>crypto: qcom-rng - Remove crypto_rng interface</p> <p>qcom-rng.c exposes the same hardware through two completely separate interfaces, crypto_rng and hwrng. However, the implementation of this is buggy because it permits generation operations from these interfaces to run concurrently with each other, accessing the same registers. That is, qcom_rng_generate() synchronizes with itself but not with qcom_hwrng_read(). This results in potential repetition of output from the RNG, output of non-random values, etc.</p> <p>Fortunately, there&#39;s actually no point in hardware RNG drivers implementing the crypto_rng interface. It&#39;s not actually used by anything besides the &#34;rng&#34; algorithm type of AF_ALG, which in turn is not actually used in practice. Other crypto_rng hardware drivers are likewise being phased out, leaving just the hwrng support.</p> <p>Thus, remove it to simplify the code and avoid conflict (and confusion) with the hwrng interface which is the one that actually matters.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>crypto: qcom-rng - Remove crypto_rng interface</p> <p>qcom-rng.c exposes the same hardware through two completely separate interfaces, crypto_rng and hwrng. However, the implementation of this is buggy because it permits generation operations from these interfaces to run concurrently with each other, accessing the same registers. That is, qcom_rng_generate() synchronizes with itself but not with qcom_hwrng_read(). This results in potential repetition of output from the RNG, output of non-random values, etc.</p> <p>Fortunately, there&#39;s actually no point in hardware RNG drivers implementing the crypto_rng interface. It&#39;s not actually used by anything besides the &#34;rng&#34; algorithm type of AF_ALG, which in turn is not actually used in practice. Other crypto_rng hardware drivers are likewise being phased out, leaving just the hwrng support.</p> <p>Thus, remove it to simplify the code and avoid conflict (and confusion) with the hwrng interface which is the one that actually matters.</p> https://cve.radiocsirt.org/vuln/ghsa-p9vr-23cc-fh67 https://cve.radiocsirt.org/vuln/opensuse-su-2026:11773-1 <p>kernel-devel-7.2.5-1.1 on GA media</p> <p>kernel-devel-7.2.5-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11773-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-80835 <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:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 154 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - Remove crypto_rng interface qcom-rng.c exposes the same hardware through two completely separate interfaces, crypto_rng and hwrng. However, the implementation of this is buggy because it permits generation operations from these interfaces to run concurrently with each other, accessing the same registers. That is, qcom_rng_generate() synchronizes with itself but not with qcom_hwrng_read(). This results in potential repetition of output from the RNG, output of non-random values, etc. Fortunately, there&#39;s actually no point in hardware RNG drivers implementing the crypto_rng interface. It&#39;s not actually used by anything besides the &#34;rng&#34; algorithm type of AF_ALG, which in turn is not actually used in practice. Other crypto_rng hardware drivers are likewise being phased out, leaving just the hwrng support. Thus, remove it to simplify the code and avoid conflict (and confusion) with the hwrng interface which is the one that actually matters.</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:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 154 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - Remove crypto_rng interface qcom-rng.c exposes the same hardware through two completely separate interfaces, crypto_rng and hwrng. However, the implementation of this is buggy because it permits generation operations from these interfaces to run concurrently with each other, accessing the same registers. That is, qcom_rng_generate() synchronizes with itself but not with qcom_hwrng_read(). This results in potential repetition of output from the RNG, output of non-random values, etc. Fortunately, there&#39;s actually no point in hardware RNG drivers implementing the crypto_rng interface. It&#39;s not actually used by anything besides the &#34;rng&#34; algorithm type of AF_ALG, which in turn is not actually used in practice. Other crypto_rng hardware drivers are likewise being phased out, leaving just the hwrng support. Thus, remove it to simplify the code and avoid conflict (and confusion) with the hwrng interface which is the one that actually matters.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-80835 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3211 <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um Speicherfehler und Kernel-Abstürze beziehungsweise Denial-of-Service-Zustände auszulösen, Speicher außerhalb vorgesehener Grenzen auszulesen sowie in einzelnen Fällen weitere Sicherheitsauswirkungen zu verursachen.</p> <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um Speicherfehler und Kernel-Abstürze beziehungsweise Denial-of-Service-Zustände auszulösen, Speicher außerhalb vorgesehener Grenzen auszulesen sowie in einzelnen Fällen weitere Sicherheitsauswirkungen zu verursachen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3211