<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 04 Oct 2026 13:04:10 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-80999</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-80999</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-80999</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1253 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Certaines d'entre elles permettent à un…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1253</link>
      <description>certfr-2026-avi-1253</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1253</guid>
    </item>
    <item>
      <title>EUVD-2026-366986</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-366986</link>
      <description>EUVD-2026-366986</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-366986</guid>
    </item>
    <item>
      <title>fkie_cve-2026-80999</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-80999</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO&lt;/p&gt;
&lt;p&gt;rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from
the probe path, which may sleep and is not timing-critical.  When the
reset GPIO is provided by a sleeping controller such as an I2C I/O
expander, gpiod_set_value() warns:&lt;/p&gt;
&lt;p&gt;WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61
  Hardware name: B&amp;amp;O MAP CA33 Rev f (UNKNOWN) (DT)
  Workqueue: events_unbound deferred_probe_work_func
  pc : gpiod_set_value+0x44/0x80
  lr : rtl83xx_probe+0x1d8/0x3a0
  Call trace:
   gpiod_set_value+0x44/0x80 (P)
   rtl83xx_probe+0x1d8/0x3a0
   realtek_mdio_probe+0x24/0xa0
   mdio_probe+0x38/0x78
   really_probe+0xc4/0x3e0
   __driver_probe_device+0x15c/0x1b8
   driver_probe_device+0xb4/0x120
   __device_attach_driver+0xb8/0x1a0
   bus_for_each_drv+0x88/0xf0
   __device_attach+0xa0/0x1d8
   device_initial_probe+0x54/0x68
   bus_probe_device+0x38/0xa0
   deferred_probe_work_func+0xb8/0x120
   process_one_work+0x184/0x4e8
   worker_thread+0x188/0x308
   kthread+0x130/0x150
   ret_from_fork+0x10/0x20&lt;/p&gt;
&lt;p&gt;Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can
be used without triggering the warning.&lt;/p&gt;
&lt;p&gt;The reset GPIO has been driven with the non-sleeping gpiod_set_value()
since the driver was added in v4.19.  The call has since been refactored
across several files - from realtek-smi.c / realtek-mdi…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO&lt;/p&gt;
&lt;p&gt;rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from
the probe path, which may sleep and is not timing-critical.  When the
reset GPIO is provided by a sleeping controller such as an I2C I/O
expander, gpiod_set_value() warns:&lt;/p&gt;
&lt;p&gt;WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61
  Hardware name: B&amp;amp;O MAP CA33 Rev f (UNKNOWN) (DT)
  Workqueue: events_unbound deferred_probe_work_func
  pc : gpiod_set_value+0x44/0x80
  lr : rtl83xx_probe+0x1d8/0x3a0
  Call trace:
   gpiod_set_value+0x44/0x80 (P)
   rtl83xx_probe+0x1d8/0x3a0
   realtek_mdio_probe+0x24/0xa0
   mdio_probe+0x38/0x78
   really_probe+0xc4/0x3e0
   __driver_probe_device+0x15c/0x1b8
   driver_probe_device+0xb4/0x120
   __device_attach_driver+0xb8/0x1a0
   bus_for_each_drv+0x88/0xf0
   __device_attach+0xa0/0x1d8
   device_initial_probe+0x54/0x68
   bus_probe_device+0x38/0xa0
   deferred_probe_work_func+0xb8/0x120
   process_one_work+0x184/0x4e8
   worker_thread+0x188/0x308
   kthread+0x130/0x150
   ret_from_fork+0x10/0x20&lt;/p&gt;
&lt;p&gt;Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can
be used without triggering the warning.&lt;/p&gt;
&lt;p&gt;The reset GPIO has been driven with the non-sleeping gpiod_set_value()
since the driver was added in v4.19.  The call has since been refactored
across several files - from realtek-smi.c / realtek-mdi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-80999</guid>
    </item>
    <item>
      <title>GHSA-5x4g-x6mc-9fxq</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-5x4g-x6mc-9fxq</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO&lt;/p&gt;
&lt;p&gt;rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from
the probe path, which may sleep and is not timing-critical.  When the
reset GPIO is provided by a sleeping controller such as an I2C I/O
expander, gpiod_set_value() warns:&lt;/p&gt;
&lt;p&gt;WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61
  Hardware name: B&amp;amp;O MAP CA33 Rev f (UNKNOWN) (DT)
  Workqueue: events_unbound deferred_probe_work_func
  pc : gpiod_set_value+0x44/0x80
  lr : rtl83xx_probe+0x1d8/0x3a0
  Call trace:
   gpiod_set_value+0x44/0x80 (P)
   rtl83xx_probe+0x1d8/0x3a0
   realtek_mdio_probe+0x24/0xa0
   mdio_probe+0x38/0x78
   really_probe+0xc4/0x3e0
   __driver_probe_device+0x15c/0x1b8
   driver_probe_device+0xb4/0x120
   __device_attach_driver+0xb8/0x1a0
   bus_for_each_drv+0x88/0xf0
   __device_attach+0xa0/0x1d8
   device_initial_probe+0x54/0x68
   bus_probe_device+0x38/0xa0
   deferred_probe_work_func+0xb8/0x120
   process_one_work+0x184/0x4e8
   worker_thread+0x188/0x308
   kthread+0x130/0x150
   ret_from_fork+0x10/0x20&lt;/p&gt;
&lt;p&gt;Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can
be used without triggering the warning.&lt;/p&gt;
&lt;p&gt;The reset GPIO has been driven with the non-sleeping gpiod_set_value()
since the driver was added in v4.19.  The call has since been refactored
across several files - from realtek-smi.c / realtek-mdi…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO&lt;/p&gt;
&lt;p&gt;rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from
the probe path, which may sleep and is not timing-critical.  When the
reset GPIO is provided by a sleeping controller such as an I2C I/O
expander, gpiod_set_value() warns:&lt;/p&gt;
&lt;p&gt;WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61
  Hardware name: B&amp;amp;O MAP CA33 Rev f (UNKNOWN) (DT)
  Workqueue: events_unbound deferred_probe_work_func
  pc : gpiod_set_value+0x44/0x80
  lr : rtl83xx_probe+0x1d8/0x3a0
  Call trace:
   gpiod_set_value+0x44/0x80 (P)
   rtl83xx_probe+0x1d8/0x3a0
   realtek_mdio_probe+0x24/0xa0
   mdio_probe+0x38/0x78
   really_probe+0xc4/0x3e0
   __driver_probe_device+0x15c/0x1b8
   driver_probe_device+0xb4/0x120
   __device_attach_driver+0xb8/0x1a0
   bus_for_each_drv+0x88/0xf0
   __device_attach+0xa0/0x1d8
   device_initial_probe+0x54/0x68
   bus_probe_device+0x38/0xa0
   deferred_probe_work_func+0xb8/0x120
   process_one_work+0x184/0x4e8
   worker_thread+0x188/0x308
   kthread+0x130/0x150
   ret_from_fork+0x10/0x20&lt;/p&gt;
&lt;p&gt;Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can
be used without triggering the warning.&lt;/p&gt;
&lt;p&gt;The reset GPIO has been driven with the non-sleeping gpiod_set_value()
since the driver was added in v4.19.  The call has since been refactored
across several files - from realtek-smi.c / realtek-mdi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-5x4g-x6mc-9fxq</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-80999 — net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-80999</link>
      <description>msrc_CVE-2026-80999</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-80999</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11805-1 — kernel-devel-7.2.6-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11805-1</link>
      <description>&lt;p&gt;kernel-devel-7.2.6-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.2.6-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11805-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-80999</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-80999</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from the probe path, which may sleep and is not timing-critical.  When the reset GPIO is provided by a sleeping controller such as an I2C I/O expander, gpiod_set_value() warns:   WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61   Hardware name: B&amp;amp;O MAP CA33 Rev f (UNKNOWN) (DT)   Workqueue: events_unbound deferred_probe_work_func   pc : gpiod_set_value+0x44/0x80   lr : rtl83xx_probe+0x1d8/0x3a0   Call trace:    gpiod_set_value+0x44/0x80 (P)    rtl83xx_probe+0x1d8/0x3a0    realtek_mdio_probe+0x24/0xa0    mdio_probe+0x38/0x78    really_probe+0xc4/0x3e0    __driver_probe_device+0x15c/0x1b8    driver_probe_device+0xb4/0x120    __device_attach_driver+0xb8/0x1a0    bus_for_each_drv+0x88/0xf0    __device_attach+0xa0/0x1d8    device_initial_probe+0x54/0x68    bus_probe_device+0x38/0xa0    deferred_probe_work_func+0xb8/0x120    process_one_work+0x184/0x4e8    worker_thread+0x188/0x308    kthread+0x130/0x150    ret_from_fork+0x10/0x20 Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can be used without triggering the warning. The reset GPIO has been driven with the non-sleeping gpiod_set_value() since the driver was added in v4.19.  The call has since been refactored across several files - from realtek-smi.c / realtek-mdio.c i…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from the probe path, which may sleep and is not timing-critical.  When the reset GPIO is provided by a sleeping controller such as an I2C I/O expander, gpiod_set_value() warns:   WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61   Hardware name: B&amp;amp;O MAP CA33 Rev f (UNKNOWN) (DT)   Workqueue: events_unbound deferred_probe_work_func   pc : gpiod_set_value+0x44/0x80   lr : rtl83xx_probe+0x1d8/0x3a0   Call trace:    gpiod_set_value+0x44/0x80 (P)    rtl83xx_probe+0x1d8/0x3a0    realtek_mdio_probe+0x24/0xa0    mdio_probe+0x38/0x78    really_probe+0xc4/0x3e0    __driver_probe_device+0x15c/0x1b8    driver_probe_device+0xb4/0x120    __device_attach_driver+0xb8/0x1a0    bus_for_each_drv+0x88/0xf0    __device_attach+0xa0/0x1d8    device_initial_probe+0x54/0x68    bus_probe_device+0x38/0xa0    deferred_probe_work_func+0xb8/0x120    process_one_work+0x184/0x4e8    worker_thread+0x188/0x308    kthread+0x130/0x150    ret_from_fork+0x10/0x20 Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can be used without triggering the warning. The reset GPIO has been driven with the non-sleeping gpiod_set_value() since the driver was added in v4.19.  The call has since been refactored across several files - from realtek-smi.c / realtek-mdio.c i…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-80999</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3321 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3321</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsmaßnahmen zu umgehen, Daten oder den Systemzustand zu manipulieren, Denial-of-Service-Zustände herbeizuführen oder andere, nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsmaßnahmen zu umgehen, Daten oder den Systemzustand zu manipulieren, Denial-of-Service-Zustände herbeizuführen oder andere, nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3321</guid>
    </item>
  </channel>
</rss>
