https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 21:14:46 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-12336 bdu:2026-12336 https://cve.radiocsirt.org/vuln/bdu:2026-12336 https://cve.radiocsirt.org/vuln/bell-cve-2026-23367 <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-2026-23367 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0376 certfr-2026-avi-0376 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0376 https://cve.radiocsirt.org/vuln/euvd-2026-315504 EUVD-2026-315504 https://cve.radiocsirt.org/vuln/euvd-2026-315504 https://cve.radiocsirt.org/vuln/fkie_cve-2026-23367 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: radiotap: reject radiotap with unknown bits</p> <p>The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator-&gt;_next_ns_data isn&#39;t initialized (it&#39;s only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value.</p> <p>Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator-&gt;_next_ns_data only for vendor namespaces, even in case undefined fields are present.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: radiotap: reject radiotap with unknown bits</p> <p>The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator-&gt;_next_ns_data isn&#39;t initialized (it&#39;s only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value.</p> <p>Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator-&gt;_next_ns_data only for vendor namespaces, even in case undefined fields are present.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-23367 https://cve.radiocsirt.org/vuln/ghsa-mg4x-3g76-43w7 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: radiotap: reject radiotap with unknown bits</p> <p>The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator-&gt;_next_ns_data isn&#39;t initialized (it&#39;s only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value.</p> <p>Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator-&gt;_next_ns_data only for vendor namespaces, even in case undefined fields are present.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>wifi: radiotap: reject radiotap with unknown bits</p> <p>The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator-&gt;_next_ns_data isn&#39;t initialized (it&#39;s only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value.</p> <p>Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator-&gt;_next_ns_data only for vendor namespaces, even in case undefined fields are present.</p> https://cve.radiocsirt.org/vuln/ghsa-mg4x-3g76-43w7 https://cve.radiocsirt.org/vuln/msrc_cve-2026-23367 msrc_CVE-2026-23367 https://cve.radiocsirt.org/vuln/msrc_cve-2026-23367 https://cve.radiocsirt.org/vuln/opensuse-su-2026:20826-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:20826-1 https://cve.radiocsirt.org/vuln/suse-su-2026:21834-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:21834-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23367 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 232 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: wifi: radiotap: reject radiotap with unknown bits The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator-&gt;_next_ns_data isn&#39;t initialized (it&#39;s only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value. Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator-&gt;_next_ns_data only for vendor namespaces, even in case undefined fields are present.</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 232 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: wifi: radiotap: reject radiotap with unknown bits The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator-&gt;_next_ns_data isn&#39;t initialized (it&#39;s only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value. Fix this by moving the rejection of unknown radiotap fields down to after the in-namespace lookup, so it will really use iterator-&gt;_next_ns_data only for vendor namespaces, even in case undefined fields are present.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23367 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