https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 10:23:08 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-12168 bdu:2026-12168 https://cve.radiocsirt.org/vuln/bdu:2026-12168 https://cve.radiocsirt.org/vuln/bell-cve-2026-23380 <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-23380 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0548 certfr-2026-avi-0548 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0548 https://cve.radiocsirt.org/vuln/euvd-2026-315511 EUVD-2026-315511 https://cve.radiocsirt.org/vuln/euvd-2026-315511 https://cve.radiocsirt.org/vuln/fkie_cve-2026-23380 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tracing: Fix WARN_ON in tracing_buffers_mmap_close</p> <p>When a process forks, the child process copies the parent&#39;s VMAs but the user_mapped reference count is not incremented. As a result, when both the parent and child processes exit, tracing_buffers_mmap_close() is called twice. On the second call, user_mapped is already 0, causing the function to return -ENODEV and triggering a WARN_ON.</p> <p>Normally, this isn&#39;t an issue as the memory is mapped with VM_DONTCOPY set. But this is only a hint, and the application can call madvise(MADVISE_DOFORK) which resets the VM_DONTCOPY flag. When the application does that, it can trigger this issue on fork.</p> <p>Fix it by incrementing the user_mapped reference count without re-mapping the pages in the VMA&#39;s open callback.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tracing: Fix WARN_ON in tracing_buffers_mmap_close</p> <p>When a process forks, the child process copies the parent&#39;s VMAs but the user_mapped reference count is not incremented. As a result, when both the parent and child processes exit, tracing_buffers_mmap_close() is called twice. On the second call, user_mapped is already 0, causing the function to return -ENODEV and triggering a WARN_ON.</p> <p>Normally, this isn&#39;t an issue as the memory is mapped with VM_DONTCOPY set. But this is only a hint, and the application can call madvise(MADVISE_DOFORK) which resets the VM_DONTCOPY flag. When the application does that, it can trigger this issue on fork.</p> <p>Fix it by incrementing the user_mapped reference count without re-mapping the pages in the VMA&#39;s open callback.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-23380 https://cve.radiocsirt.org/vuln/ghsa-q6xr-q445-2xxh <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tracing: Fix WARN_ON in tracing_buffers_mmap_close</p> <p>When a process forks, the child process copies the parent&#39;s VMAs but the user_mapped reference count is not incremented. As a result, when both the parent and child processes exit, tracing_buffers_mmap_close() is called twice. On the second call, user_mapped is already 0, causing the function to return -ENODEV and triggering a WARN_ON.</p> <p>Normally, this isn&#39;t an issue as the memory is mapped with VM_DONTCOPY set. But this is only a hint, and the application can call madvise(MADVISE_DOFORK) which resets the VM_DONTCOPY flag. When the application does that, it can trigger this issue on fork.</p> <p>Fix it by incrementing the user_mapped reference count without re-mapping the pages in the VMA&#39;s open callback.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tracing: Fix WARN_ON in tracing_buffers_mmap_close</p> <p>When a process forks, the child process copies the parent&#39;s VMAs but the user_mapped reference count is not incremented. As a result, when both the parent and child processes exit, tracing_buffers_mmap_close() is called twice. On the second call, user_mapped is already 0, causing the function to return -ENODEV and triggering a WARN_ON.</p> <p>Normally, this isn&#39;t an issue as the memory is mapped with VM_DONTCOPY set. But this is only a hint, and the application can call madvise(MADVISE_DOFORK) which resets the VM_DONTCOPY flag. When the application does that, it can trigger this issue on fork.</p> <p>Fix it by incrementing the user_mapped reference count without re-mapping the pages in the VMA&#39;s open callback.</p> https://cve.radiocsirt.org/vuln/ghsa-q6xr-q445-2xxh https://cve.radiocsirt.org/vuln/opensuse-su-2026:20912-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:20912-1 https://cve.radiocsirt.org/vuln/suse-su-2026:22043-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:22043-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23380 <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 106 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close When a process forks, the child process copies the parent&#39;s VMAs but the user_mapped reference count is not incremented. As a result, when both the parent and child processes exit, tracing_buffers_mmap_close() is called twice. On the second call, user_mapped is already 0, causing the function to return -ENODEV and triggering a WARN_ON. Normally, this isn&#39;t an issue as the memory is mapped with VM_DONTCOPY set. But this is only a hint, and the application can call madvise(MADVISE_DOFORK) which resets the VM_DONTCOPY flag. When the application does that, it can trigger this issue on fork. Fix it by incrementing the user_mapped reference count without re-mapping the pages in the VMA&#39;s open callback.</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 106 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close When a process forks, the child process copies the parent&#39;s VMAs but the user_mapped reference count is not incremented. As a result, when both the parent and child processes exit, tracing_buffers_mmap_close() is called twice. On the second call, user_mapped is already 0, causing the function to return -ENODEV and triggering a WARN_ON. Normally, this isn&#39;t an issue as the memory is mapped with VM_DONTCOPY set. But this is only a hint, and the application can call madvise(MADVISE_DOFORK) which resets the VM_DONTCOPY flag. When the application does that, it can trigger this issue on fork. Fix it by incrementing the user_mapped reference count without re-mapping the pages in the VMA&#39;s open callback.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23380 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0861 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, weitere nicht spezifizierte Auswirkungen zu verursachen und potentiell Code auszuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, weitere nicht spezifizierte Auswirkungen zu verursachen und potentiell Code auszuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0861