https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 06:45:27 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-11995 bdu:2026-11995 https://cve.radiocsirt.org/vuln/bdu:2026-11995 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166 certfr-2026-avi-0166 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166 https://cve.radiocsirt.org/vuln/euvd-2026-321617 EUVD-2026-321617 https://cve.radiocsirt.org/vuln/euvd-2026-321617 https://cve.radiocsirt.org/vuln/fkie_cve-2025-71140 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>media: mediatek: vcodec: Use spinlock for context list protection lock</p> <p>Previously a mutex was added to protect the encoder and decoder context lists from unexpected changes originating from the SCP IP block, causing the context pointer to go invalid, resulting in a NULL pointer dereference in the IPI handler.</p> <p>Turns out on the MT8173, the VPU IPI handler is called from hard IRQ context. This causes a big warning from the scheduler. This was first reported downstream on the ChromeOS kernels, but is also reproducible on mainline using Fluster with the FFmpeg v4l2m2m decoders. Even though the actual capture format is not supported, the affected code paths are triggered.</p> <p>Since this lock just protects the context list and operations on it are very fast, it should be OK to switch to a spinlock.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>media: mediatek: vcodec: Use spinlock for context list protection lock</p> <p>Previously a mutex was added to protect the encoder and decoder context lists from unexpected changes originating from the SCP IP block, causing the context pointer to go invalid, resulting in a NULL pointer dereference in the IPI handler.</p> <p>Turns out on the MT8173, the VPU IPI handler is called from hard IRQ context. This causes a big warning from the scheduler. This was first reported downstream on the ChromeOS kernels, but is also reproducible on mainline using Fluster with the FFmpeg v4l2m2m decoders. Even though the actual capture format is not supported, the affected code paths are triggered.</p> <p>Since this lock just protects the context list and operations on it are very fast, it should be OK to switch to a spinlock.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-71140 https://cve.radiocsirt.org/vuln/ghsa-fmmj-6v74-3cm2 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>media: mediatek: vcodec: Use spinlock for context list protection lock</p> <p>Previously a mutex was added to protect the encoder and decoder context lists from unexpected changes originating from the SCP IP block, causing the context pointer to go invalid, resulting in a NULL pointer dereference in the IPI handler.</p> <p>Turns out on the MT8173, the VPU IPI handler is called from hard IRQ context. This causes a big warning from the scheduler. This was first reported downstream on the ChromeOS kernels, but is also reproducible on mainline using Fluster with the FFmpeg v4l2m2m decoders. Even though the actual capture format is not supported, the affected code paths are triggered.</p> <p>Since this lock just protects the context list and operations on it are very fast, it should be OK to switch to a spinlock.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>media: mediatek: vcodec: Use spinlock for context list protection lock</p> <p>Previously a mutex was added to protect the encoder and decoder context lists from unexpected changes originating from the SCP IP block, causing the context pointer to go invalid, resulting in a NULL pointer dereference in the IPI handler.</p> <p>Turns out on the MT8173, the VPU IPI handler is called from hard IRQ context. This causes a big warning from the scheduler. This was first reported downstream on the ChromeOS kernels, but is also reproducible on mainline using Fluster with the FFmpeg v4l2m2m decoders. Even though the actual capture format is not supported, the affected code paths are triggered.</p> <p>Since this lock just protects the context list and operations on it are very fast, it should be OK to switch to a spinlock.</p> https://cve.radiocsirt.org/vuln/ghsa-fmmj-6v74-3cm2 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71140 <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 140 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Use spinlock for context list protection lock Previously a mutex was added to protect the encoder and decoder context lists from unexpected changes originating from the SCP IP block, causing the context pointer to go invalid, resulting in a NULL pointer dereference in the IPI handler. Turns out on the MT8173, the VPU IPI handler is called from hard IRQ context. This causes a big warning from the scheduler. This was first reported downstream on the ChromeOS kernels, but is also reproducible on mainline using Fluster with the FFmpeg v4l2m2m decoders. Even though the actual capture format is not supported, the affected code paths are triggered. Since this lock just protects the context list and operations on it are very fast, it should be OK to switch to a spinlock.</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 140 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Use spinlock for context list protection lock Previously a mutex was added to protect the encoder and decoder context lists from unexpected changes originating from the SCP IP block, causing the context pointer to go invalid, resulting in a NULL pointer dereference in the IPI handler. Turns out on the MT8173, the VPU IPI handler is called from hard IRQ context. This causes a big warning from the scheduler. This was first reported downstream on the ChromeOS kernels, but is also reproducible on mainline using Fluster with the FFmpeg v4l2m2m decoders. Even though the actual capture format is not supported, the affected code paths are triggered. Since this lock just protects the context list and operations on it are very fast, it should be OK to switch to a spinlock.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71140 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0119 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0119