<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T10:43:49.207644+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0252</id>
    <title>certfr-2025-avi-0252 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
    <updated>2026-10-02T10:43:49.466350+00:00</updated>
    <content>certfr-2025-avi-0252</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2025-avi-0252"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-351816</id>
    <title>EUVD-2026-351816</title>
    <updated>2026-10-02T10:43:49.466416+00:00</updated>
    <content>EUVD-2026-351816</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-351816"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2022-49309</id>
    <title>fkie_cve-2022-49309</title>
    <updated>2026-10-02T10:43:49.466431+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()</p>
<p>There is a deadlock in rtw_surveydone_event_callback(),
which is shown below:</p>
<p>(Thread 1)                  |      (Thread 2)
                               | _set_timer()
rtw_surveydone_event_callback()|  mod_timer()
 spin_lock_bh() //(1)          |  (wait a time)
 ...                           | rtw_scan_timeout_handler()
 del_timer_sync()              |  spin_lock_bh() //(2)
 (wait timer to stop)          |  ...</p>
<p>We hold pmlmepriv-&gt;lock in position (1) of thread 1 and use
del_timer_sync() to wait timer to stop, but timer handler
also need pmlmepriv-&gt;lock in position (2) of thread 2.
As a result, rtw_surveydone_event_callback() will block forever.</p>
<p>This patch extracts del_timer_sync() from the protection of
spin_lock_bh(), which could let timer handler to obtain
the needed lock. What`s more, we change spin_lock_bh() in
rtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,
spin_lock_bh() will also cause deadlock() in timer handler.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2022-49309"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-xpwf-pw24-jcwf</id>
    <title>GHSA-xpwf-pw24-jcwf</title>
    <updated>2026-10-02T10:43:49.466474+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()</p>
<p>There is a deadlock in rtw_surveydone_event_callback(),
which is shown below:</p>
<p>(Thread 1)                  |      (Thread 2)
                               | _set_timer()
rtw_surveydone_event_callback()|  mod_timer()
 spin_lock_bh() //(1)          |  (wait a time)
 ...                           | rtw_scan_timeout_handler()
 del_timer_sync()              |  spin_lock_bh() //(2)
 (wait timer to stop)          |  ...</p>
<p>We hold pmlmepriv-&gt;lock in position (1) of thread 1 and use
del_timer_sync() to wait timer to stop, but timer handler
also need pmlmepriv-&gt;lock in position (2) of thread 2.
As a result, rtw_surveydone_event_callback() will block forever.</p>
<p>This patch extracts del_timer_sync() from the protection of
spin_lock_bh(), which could let timer handler to obtain
the needed lock. What`s more, we change spin_lock_bh() in
rtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,
spin_lock_bh() will also cause deadlock() in timer handler.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-xpwf-pw24-jcwf"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/oesa-2026-1341</id>
    <title>OESA-2026-1341 — kernel security update</title>
    <updated>2026-10-02T10:43:49.466500+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p>
<p>The Linux Kernel, the operating system core itself.

Security Fix(es):</p>
<p>In the Linux kernel, the following vulnerability has been resolved:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ( mem hotunplug: fix kfree() of bootmemmemory ), we could get a resource allocated during boot viaalloc_resource().  And it s required to release the resource usingfree_resource().  Howerver, many people use kfree directly which willresult in kernel BUG.  In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.(CVE-2022-49190)</p>
<p>In the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()There is a deadlock in rtw_surveydone_event_callback(),which is shown below:   (Thread 1)                  |      (Thread 2)                               | _set_timer()rtw_surveydone_event_callback()|  mod_timer() spin_lock_bh() //(1)          |  (wait a time) ...                           | rtw_scan_timeout_handler() del_timer_sync()              |  spin_lock_bh() //(2) (wait timer to stop)          |  ...We hold pmlmepriv-&amp;gt;lock in position (1) of thread 1 and usedel_timer_sync() to wait timer to stop, but timer handleralso need pmlmepriv-&amp;gt;lock in position (2) of thread 2.As a result, rtw_surveydone_event_callback() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_bh(), which could let timer handler to obta…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/oesa-2026-1341"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2025:1176-1</id>
    <title>SUSE-SU-2025:1176-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-02T10:43:49.466876+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2025:1176-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49309</id>
    <title>UBUNTU-CVE-2022-49309</title>
    <updated>2026-10-02T10:43:49.467254+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><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 146 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback() There is a deadlock in rtw_surveydone_event_callback(), which is shown below:    (Thread 1)                  |      (Thread 2)                                | _set_timer() rtw_surveydone_event_callback()|  mod_timer()  spin_lock_bh() //(1)          |  (wait a time)  ...                           | rtw_scan_timeout_handler()  del_timer_sync()              |  spin_lock_bh() //(2)  (wait timer to stop)          |  ... We hold pmlmepriv-&gt;lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need pmlmepriv-&gt;lock in position (2) of thread 2. As a result, rtw_surveydone_event_callback() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_bh(), which could let timer handler to obtain the needed lock. What`s more, we change spin_lock_bh() in rtw_scan_timeout_handler() to spin_lock_irq(). Otherwise, spin_lock_bh() will also cause deadlock() in timer handler.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49309"/>
  </entry>
</feed>
