<?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>Mon, 19 Oct 2026 03:21:45 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-03995</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-03995</link>
      <description>bdu:2026-03995</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-03995</guid>
    </item>
    <item>
      <title>EUVD-2026-310744</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-310744</link>
      <description>EUVD-2026-310744</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-310744</guid>
    </item>
    <item>
      <title>fkie_cve-2022-49702</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-49702</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: fix hang during unmount when block group reclaim task is running&lt;/p&gt;
&lt;p&gt;When we start an unmount, at close_ctree(), if we have the reclaim task
running and in the middle of a data block group relocation, we can trigger
a deadlock when stopping an async reclaim task, producing a trace like the
following:&lt;/p&gt;
&lt;p&gt;[629724.498185] task:kworker/u16:7   state:D stack:    0 pid:681170 ppid:     2 flags:0x00004000
[629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]
[629724.501267] Call Trace:
[629724.501759]  &amp;lt;TASK&amp;gt;
[629724.502174]  __schedule+0x3cb/0xed0
[629724.502842]  schedule+0x4e/0xb0
[629724.503447]  btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs]
[629724.504534]  ? prepare_to_wait_exclusive+0xc0/0xc0
[629724.505442]  flush_space+0x423/0x630 [btrfs]
[629724.506296]  ? rcu_read_unlock_trace_special+0x20/0x50
[629724.507259]  ? lock_release+0x220/0x4a0
[629724.507932]  ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs]
[629724.508940]  ? do_raw_spin_unlock+0x4b/0xa0
[629724.509688]  btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs]
[629724.510922]  process_one_work+0x252/0x5a0
[629724.511694]  ? process_one_work+0x5a0/0x5a0
[629724.512508]  worker_thread+0x52/0x3b0
[629724.513220]  ? process_one_work+0x5a0/0x5a0
[629724.514021]  kthread+0xf2/0x120
[629724.514627]  ? kthread_complete_and_exit+0x20/0x20
[629724.515526]  ret_from_fork+0x22/0x30
[629724.516236]  &amp;lt;/TASK&amp;gt;
[629724.516694] task…&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;btrfs: fix hang during unmount when block group reclaim task is running&lt;/p&gt;
&lt;p&gt;When we start an unmount, at close_ctree(), if we have the reclaim task
running and in the middle of a data block group relocation, we can trigger
a deadlock when stopping an async reclaim task, producing a trace like the
following:&lt;/p&gt;
&lt;p&gt;[629724.498185] task:kworker/u16:7   state:D stack:    0 pid:681170 ppid:     2 flags:0x00004000
[629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]
[629724.501267] Call Trace:
[629724.501759]  &amp;lt;TASK&amp;gt;
[629724.502174]  __schedule+0x3cb/0xed0
[629724.502842]  schedule+0x4e/0xb0
[629724.503447]  btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs]
[629724.504534]  ? prepare_to_wait_exclusive+0xc0/0xc0
[629724.505442]  flush_space+0x423/0x630 [btrfs]
[629724.506296]  ? rcu_read_unlock_trace_special+0x20/0x50
[629724.507259]  ? lock_release+0x220/0x4a0
[629724.507932]  ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs]
[629724.508940]  ? do_raw_spin_unlock+0x4b/0xa0
[629724.509688]  btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs]
[629724.510922]  process_one_work+0x252/0x5a0
[629724.511694]  ? process_one_work+0x5a0/0x5a0
[629724.512508]  worker_thread+0x52/0x3b0
[629724.513220]  ? process_one_work+0x5a0/0x5a0
[629724.514021]  kthread+0xf2/0x120
[629724.514627]  ? kthread_complete_and_exit+0x20/0x20
[629724.515526]  ret_from_fork+0x22/0x30
[629724.516236]  &amp;lt;/TASK&amp;gt;
[629724.516694] task…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-49702</guid>
    </item>
    <item>
      <title>GHSA-6hq8-g74x-24q3</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-6hq8-g74x-24q3</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: fix hang during unmount when block group reclaim task is running&lt;/p&gt;
&lt;p&gt;When we start an unmount, at close_ctree(), if we have the reclaim task
running and in the middle of a data block group relocation, we can trigger
a deadlock when stopping an async reclaim task, producing a trace like the
following:&lt;/p&gt;
&lt;p&gt;[629724.498185] task:kworker/u16:7   state:D stack:    0 pid:681170 ppid:     2 flags:0x00004000
[629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]
[629724.501267] Call Trace:
[629724.501759]  &amp;lt;TASK&amp;gt;
[629724.502174]  __schedule+0x3cb/0xed0
[629724.502842]  schedule+0x4e/0xb0
[629724.503447]  btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs]
[629724.504534]  ? prepare_to_wait_exclusive+0xc0/0xc0
[629724.505442]  flush_space+0x423/0x630 [btrfs]
[629724.506296]  ? rcu_read_unlock_trace_special+0x20/0x50
[629724.507259]  ? lock_release+0x220/0x4a0
[629724.507932]  ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs]
[629724.508940]  ? do_raw_spin_unlock+0x4b/0xa0
[629724.509688]  btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs]
[629724.510922]  process_one_work+0x252/0x5a0
[629724.511694]  ? process_one_work+0x5a0/0x5a0
[629724.512508]  worker_thread+0x52/0x3b0
[629724.513220]  ? process_one_work+0x5a0/0x5a0
[629724.514021]  kthread+0xf2/0x120
[629724.514627]  ? kthread_complete_and_exit+0x20/0x20
[629724.515526]  ret_from_fork+0x22/0x30
[629724.516236]  &amp;lt;/TASK&amp;gt;
[629724.516694] task…&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;btrfs: fix hang during unmount when block group reclaim task is running&lt;/p&gt;
&lt;p&gt;When we start an unmount, at close_ctree(), if we have the reclaim task
running and in the middle of a data block group relocation, we can trigger
a deadlock when stopping an async reclaim task, producing a trace like the
following:&lt;/p&gt;
&lt;p&gt;[629724.498185] task:kworker/u16:7   state:D stack:    0 pid:681170 ppid:     2 flags:0x00004000
[629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]
[629724.501267] Call Trace:
[629724.501759]  &amp;lt;TASK&amp;gt;
[629724.502174]  __schedule+0x3cb/0xed0
[629724.502842]  schedule+0x4e/0xb0
[629724.503447]  btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs]
[629724.504534]  ? prepare_to_wait_exclusive+0xc0/0xc0
[629724.505442]  flush_space+0x423/0x630 [btrfs]
[629724.506296]  ? rcu_read_unlock_trace_special+0x20/0x50
[629724.507259]  ? lock_release+0x220/0x4a0
[629724.507932]  ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs]
[629724.508940]  ? do_raw_spin_unlock+0x4b/0xa0
[629724.509688]  btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs]
[629724.510922]  process_one_work+0x252/0x5a0
[629724.511694]  ? process_one_work+0x5a0/0x5a0
[629724.512508]  worker_thread+0x52/0x3b0
[629724.513220]  ? process_one_work+0x5a0/0x5a0
[629724.514021]  kthread+0xf2/0x120
[629724.514627]  ? kthread_complete_and_exit+0x20/0x20
[629724.515526]  ret_from_fork+0x22/0x30
[629724.516236]  &amp;lt;/TASK&amp;gt;
[629724.516694] task…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-6hq8-g74x-24q3</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-49702</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49702</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: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 92 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: btrfs: fix hang during unmount when block group reclaim task is running When we start an unmount, at close_ctree(), if we have the reclaim task running and in the middle of a data block group relocation, we can trigger a deadlock when stopping an async reclaim task, producing a trace like the following: [629724.498185] task:kworker/u16:7   state:D stack:    0 pid:681170 ppid:   2 flags:0x00004000 [629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs] [629724.501267] Call Trace: [629724.501759]  &amp;lt;TASK&amp;gt; [629724.502174]  __schedule+0x3cb/0xed0 [629724.502842]  schedule+0x4e/0xb0 [629724.503447]  btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs] [629724.504534]  ? prepare_to_wait_exclusive+0xc0/0xc0 [629724.505442]  flush_space+0x423/0x630 [btrfs] [629724.506296]  ? rcu_read_unlock_trace_special+0x20/0x50 [629724.507259]  ? lock_release+0x220/0x4a0 [629724.507932]  ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs] [629724.508940]  ? do_raw_spin_unlock+0x4b/0xa0 [629724.509688]  btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs] [629724.510922]  process_one_work+0x252/0x5a0 [629724.511694]  ? process_one_work+0x5a0/0x5a0 [629724.512508]  worker_thread+0x52/0x3b0 [629724.513220]  ? process_one_work+0x5a0/0x5a0 [629724.514021]  kthread+0xf2/0x120 [629724.514627]  ? kthread_complete_and_exit+0x20/0x20 [629724.515526]  ret_from_fork+0x22/0x30 [629724.516236]  &amp;lt;/TASK&amp;gt; [629724.516694] task:umou…&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: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 92 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: btrfs: fix hang during unmount when block group reclaim task is running When we start an unmount, at close_ctree(), if we have the reclaim task running and in the middle of a data block group relocation, we can trigger a deadlock when stopping an async reclaim task, producing a trace like the following: [629724.498185] task:kworker/u16:7   state:D stack:    0 pid:681170 ppid:   2 flags:0x00004000 [629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs] [629724.501267] Call Trace: [629724.501759]  &amp;lt;TASK&amp;gt; [629724.502174]  __schedule+0x3cb/0xed0 [629724.502842]  schedule+0x4e/0xb0 [629724.503447]  btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs] [629724.504534]  ? prepare_to_wait_exclusive+0xc0/0xc0 [629724.505442]  flush_space+0x423/0x630 [btrfs] [629724.506296]  ? rcu_read_unlock_trace_special+0x20/0x50 [629724.507259]  ? lock_release+0x220/0x4a0 [629724.507932]  ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs] [629724.508940]  ? do_raw_spin_unlock+0x4b/0xa0 [629724.509688]  btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs] [629724.510922]  process_one_work+0x252/0x5a0 [629724.511694]  ? process_one_work+0x5a0/0x5a0 [629724.512508]  worker_thread+0x52/0x3b0 [629724.513220]  ? process_one_work+0x5a0/0x5a0 [629724.514021]  kthread+0xf2/0x120 [629724.514627]  ? kthread_complete_and_exit+0x20/0x20 [629724.515526]  ret_from_fork+0x22/0x30 [629724.516236]  &amp;lt;/TASK&amp;gt; [629724.516694] task:umou…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49702</guid>
    </item>
  </channel>
</rss>
