https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 13:34:43 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-01139 bdu:2026-01139 https://cve.radiocsirt.org/vuln/bdu:2026-01139 https://cve.radiocsirt.org/vuln/bell-cve-2023-53991 <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2023-53991 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0108 certfr-2026-avi-0108 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0108 https://cve.radiocsirt.org/vuln/euvd-2026-312301 EUVD-2026-312301 https://cve.radiocsirt.org/vuln/euvd-2026-312301 https://cve.radiocsirt.org/vuln/fkie_cve-2023-53991 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/msm/dpu: Disallow unallocated resources to be returned</p> <p>In the event that the topology requests resources that have not been created by the system (because they are typically not represented in dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC blocks, until their allocation/assignment is being sanity-checked in &#34;drm/msm/dpu: Reject topologies for which no DSC blocks are available&#34;) remain NULL but will still be returned out of dpu_rm_get_assigned_resources, where the caller expects to get an array containing num_blks valid pointers (but instead gets these NULLs).</p> <p>To prevent this from happening, where null-pointer dereferences typically result in a hard-to-debug platform lockup, num_blks shouldn&#39;t increase past NULL blocks and will print an error and break instead. After all, max_blks represents the static size of the maximum number of blocks whereas the actual amount varies per platform.</p> <p>^1: which can happen after a git rebase ended up moving additions to _dpu_cfg to a different struct which has the same patch context.</p> <p>Patchwork: https://patchwork.freedesktop.org/patch/517636/</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/msm/dpu: Disallow unallocated resources to be returned</p> <p>In the event that the topology requests resources that have not been created by the system (because they are typically not represented in dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC blocks, until their allocation/assignment is being sanity-checked in &#34;drm/msm/dpu: Reject topologies for which no DSC blocks are available&#34;) remain NULL but will still be returned out of dpu_rm_get_assigned_resources, where the caller expects to get an array containing num_blks valid pointers (but instead gets these NULLs).</p> <p>To prevent this from happening, where null-pointer dereferences typically result in a hard-to-debug platform lockup, num_blks shouldn&#39;t increase past NULL blocks and will print an error and break instead. After all, max_blks represents the static size of the maximum number of blocks whereas the actual amount varies per platform.</p> <p>^1: which can happen after a git rebase ended up moving additions to _dpu_cfg to a different struct which has the same patch context.</p> <p>Patchwork: https://patchwork.freedesktop.org/patch/517636/</p> https://cve.radiocsirt.org/vuln/fkie_cve-2023-53991 https://cve.radiocsirt.org/vuln/ghsa-8m95-4p4w-6hv6 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/msm/dpu: Disallow unallocated resources to be returned</p> <p>In the event that the topology requests resources that have not been created by the system (because they are typically not represented in dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC blocks, until their allocation/assignment is being sanity-checked in &#34;drm/msm/dpu: Reject topologies for which no DSC blocks are available&#34;) remain NULL but will still be returned out of dpu_rm_get_assigned_resources, where the caller expects to get an array containing num_blks valid pointers (but instead gets these NULLs).</p> <p>To prevent this from happening, where null-pointer dereferences typically result in a hard-to-debug platform lockup, num_blks shouldn&#39;t increase past NULL blocks and will print an error and break instead. After all, max_blks represents the static size of the maximum number of blocks whereas the actual amount varies per platform.</p> <p>^1: which can happen after a git rebase ended up moving additions to _dpu_cfg to a different struct which has the same patch context.</p> <p>Patchwork: https://patchwork.freedesktop.org/patch/517636/</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/msm/dpu: Disallow unallocated resources to be returned</p> <p>In the event that the topology requests resources that have not been created by the system (because they are typically not represented in dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC blocks, until their allocation/assignment is being sanity-checked in &#34;drm/msm/dpu: Reject topologies for which no DSC blocks are available&#34;) remain NULL but will still be returned out of dpu_rm_get_assigned_resources, where the caller expects to get an array containing num_blks valid pointers (but instead gets these NULLs).</p> <p>To prevent this from happening, where null-pointer dereferences typically result in a hard-to-debug platform lockup, num_blks shouldn&#39;t increase past NULL blocks and will print an error and break instead. After all, max_blks represents the static size of the maximum number of blocks whereas the actual amount varies per platform.</p> <p>^1: which can happen after a git rebase ended up moving additions to _dpu_cfg to a different struct which has the same patch context.</p> <p>Patchwork: https://patchwork.freedesktop.org/patch/517636/</p> https://cve.radiocsirt.org/vuln/ghsa-8m95-4p4w-6hv6 https://cve.radiocsirt.org/vuln/suse-su-2026:0263-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2026:0263-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53991 <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 107 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: Disallow unallocated resources to be returned In the event that the topology requests resources that have not been created by the system (because they are typically not represented in dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC blocks, until their allocation/assignment is being sanity-checked in &#34;drm/msm/dpu: Reject topologies for which no DSC blocks are available&#34;) remain NULL but will still be returned out of dpu_rm_get_assigned_resources, where the caller expects to get an array containing num_blks valid pointers (but instead gets these NULLs). To prevent this from happening, where null-pointer dereferences typically result in a hard-to-debug platform lockup, num_blks shouldn&#39;t increase past NULL blocks and will print an error and break instead. After all, max_blks represents the static size of the maximum number of blocks whereas the actual amount varies per platform. ^1: which can happen after a git rebase ended up moving additions to _dpu_cfg to a different struct which has the same patch context. Patchwork: https://patchwork.freedesktop.org/patch/517636/</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 107 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: Disallow unallocated resources to be returned In the event that the topology requests resources that have not been created by the system (because they are typically not represented in dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC blocks, until their allocation/assignment is being sanity-checked in &#34;drm/msm/dpu: Reject topologies for which no DSC blocks are available&#34;) remain NULL but will still be returned out of dpu_rm_get_assigned_resources, where the caller expects to get an array containing num_blks valid pointers (but instead gets these NULLs). To prevent this from happening, where null-pointer dereferences typically result in a hard-to-debug platform lockup, num_blks shouldn&#39;t increase past NULL blocks and will print an error and break instead. After all, max_blks represents the static size of the maximum number of blocks whereas the actual amount varies per platform. ^1: which can happen after a git rebase ended up moving additions to _dpu_cfg to a different struct which has the same patch context. Patchwork: https://patchwork.freedesktop.org/patch/517636/</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53991 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2920 <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-2025-2920