<?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://vulnerability.circl.lu</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, 28 Sep 2026 17:51:17 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-93241</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2026-93241</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bell-cve-2026-93241</guid>
    </item>
    <item>
      <title>fkie_cve-2026-93241</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-93241</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done&lt;/p&gt;
&lt;p&gt;At Meta, we are seeing instances where an OOM killed job is stuck in the
exit path for several hours.  In one particular case, the job was stuck
for more than 8 hours and I had to manually remove the memory.max limits
to allow the process to exit.&lt;/p&gt;
&lt;p&gt;The job was a single process job and had ~55 GiB memory.max and zswap
enabled.  It had almost 0 anon in memory and ~111 GiB in zswap compressed
to ~51 GiB zswap pool (i.e.  almost all of memory.current was zswap). 
Nothing was left on the LRUs to reclaim.&lt;/p&gt;
&lt;p&gt;On further inspection, I observed ~20k threads of that process stuck with
the following stack:&lt;/p&gt;
&lt;p&gt;[&amp;lt;0&amp;gt;] mem_cgroup_out_of_memory+0x4e/0xa0
[&amp;lt;0&amp;gt;] charge_memcg+0x8bf/0x990
[&amp;lt;0&amp;gt;] mem_cgroup_swapin_charge_folio+0x4e/0x80
[&amp;lt;0&amp;gt;] __read_swap_cache_async+0x10c/0x260
[&amp;lt;0&amp;gt;] swapin_readahead+0x116/0x3f0
[&amp;lt;0&amp;gt;] do_swap_page+0x13c/0x1ce0
[&amp;lt;0&amp;gt;] handle_mm_fault+0x61d/0x11f0
[&amp;lt;0&amp;gt;] do_user_addr_fault+0x3e7/0x6d0
[&amp;lt;0&amp;gt;] exc_page_fault+0x8f/0x110
[&amp;lt;0&amp;gt;] asm_exc_page_fault+0x22/0x30
[&amp;lt;0&amp;gt;] __get_user_8+0x14/0x20
[&amp;lt;0&amp;gt;] futex_cleanup+0x27/0x1c0
[&amp;lt;0&amp;gt;] futex_exit_release+0x47/0x60
[&amp;lt;0&amp;gt;] do_exit+0x107/0x940
[&amp;lt;0&amp;gt;] do_group_exit+0x81/0xa0
[&amp;lt;0&amp;gt;] get_signal+0x2b1/0x6e0
[&amp;lt;0&amp;gt;] arch_do_signal_or_restart+0x1a/0x1c0
[&amp;lt;0&amp;gt;] exit_to_user_mode_loop+0xa8/0x1c0
[&amp;lt;0&amp;gt;] do_syscall_64+0x152/0x250
[&amp;lt;0&amp;gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53&lt;/p&gt;
&lt;p&gt;In addition the dmesg was filled wit…&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;memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done&lt;/p&gt;
&lt;p&gt;At Meta, we are seeing instances where an OOM killed job is stuck in the
exit path for several hours.  In one particular case, the job was stuck
for more than 8 hours and I had to manually remove the memory.max limits
to allow the process to exit.&lt;/p&gt;
&lt;p&gt;The job was a single process job and had ~55 GiB memory.max and zswap
enabled.  It had almost 0 anon in memory and ~111 GiB in zswap compressed
to ~51 GiB zswap pool (i.e.  almost all of memory.current was zswap). 
Nothing was left on the LRUs to reclaim.&lt;/p&gt;
&lt;p&gt;On further inspection, I observed ~20k threads of that process stuck with
the following stack:&lt;/p&gt;
&lt;p&gt;[&amp;lt;0&amp;gt;] mem_cgroup_out_of_memory+0x4e/0xa0
[&amp;lt;0&amp;gt;] charge_memcg+0x8bf/0x990
[&amp;lt;0&amp;gt;] mem_cgroup_swapin_charge_folio+0x4e/0x80
[&amp;lt;0&amp;gt;] __read_swap_cache_async+0x10c/0x260
[&amp;lt;0&amp;gt;] swapin_readahead+0x116/0x3f0
[&amp;lt;0&amp;gt;] do_swap_page+0x13c/0x1ce0
[&amp;lt;0&amp;gt;] handle_mm_fault+0x61d/0x11f0
[&amp;lt;0&amp;gt;] do_user_addr_fault+0x3e7/0x6d0
[&amp;lt;0&amp;gt;] exc_page_fault+0x8f/0x110
[&amp;lt;0&amp;gt;] asm_exc_page_fault+0x22/0x30
[&amp;lt;0&amp;gt;] __get_user_8+0x14/0x20
[&amp;lt;0&amp;gt;] futex_cleanup+0x27/0x1c0
[&amp;lt;0&amp;gt;] futex_exit_release+0x47/0x60
[&amp;lt;0&amp;gt;] do_exit+0x107/0x940
[&amp;lt;0&amp;gt;] do_group_exit+0x81/0xa0
[&amp;lt;0&amp;gt;] get_signal+0x2b1/0x6e0
[&amp;lt;0&amp;gt;] arch_do_signal_or_restart+0x1a/0x1c0
[&amp;lt;0&amp;gt;] exit_to_user_mode_loop+0xa8/0x1c0
[&amp;lt;0&amp;gt;] do_syscall_64+0x152/0x250
[&amp;lt;0&amp;gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53&lt;/p&gt;
&lt;p&gt;In addition the dmesg was filled wit…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-93241</guid>
    </item>
    <item>
      <title>GHSA-vxm3-j3p3-g54x</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-vxm3-j3p3-g54x</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done&lt;/p&gt;
&lt;p&gt;At Meta, we are seeing instances where an OOM killed job is stuck in the
exit path for several hours.  In one particular case, the job was stuck
for more than 8 hours and I had to manually remove the memory.max limits
to allow the process to exit.&lt;/p&gt;
&lt;p&gt;The job was a single process job and had ~55 GiB memory.max and zswap
enabled.  It had almost 0 anon in memory and ~111 GiB in zswap compressed
to ~51 GiB zswap pool (i.e.  almost all of memory.current was zswap). 
Nothing was left on the LRUs to reclaim.&lt;/p&gt;
&lt;p&gt;On further inspection, I observed ~20k threads of that process stuck with
the following stack:&lt;/p&gt;
&lt;p&gt;[&amp;lt;0&amp;gt;] mem_cgroup_out_of_memory+0x4e/0xa0
[&amp;lt;0&amp;gt;] charge_memcg+0x8bf/0x990
[&amp;lt;0&amp;gt;] mem_cgroup_swapin_charge_folio+0x4e/0x80
[&amp;lt;0&amp;gt;] __read_swap_cache_async+0x10c/0x260
[&amp;lt;0&amp;gt;] swapin_readahead+0x116/0x3f0
[&amp;lt;0&amp;gt;] do_swap_page+0x13c/0x1ce0
[&amp;lt;0&amp;gt;] handle_mm_fault+0x61d/0x11f0
[&amp;lt;0&amp;gt;] do_user_addr_fault+0x3e7/0x6d0
[&amp;lt;0&amp;gt;] exc_page_fault+0x8f/0x110
[&amp;lt;0&amp;gt;] asm_exc_page_fault+0x22/0x30
[&amp;lt;0&amp;gt;] __get_user_8+0x14/0x20
[&amp;lt;0&amp;gt;] futex_cleanup+0x27/0x1c0
[&amp;lt;0&amp;gt;] futex_exit_release+0x47/0x60
[&amp;lt;0&amp;gt;] do_exit+0x107/0x940
[&amp;lt;0&amp;gt;] do_group_exit+0x81/0xa0
[&amp;lt;0&amp;gt;] get_signal+0x2b1/0x6e0
[&amp;lt;0&amp;gt;] arch_do_signal_or_restart+0x1a/0x1c0
[&amp;lt;0&amp;gt;] exit_to_user_mode_loop+0xa8/0x1c0
[&amp;lt;0&amp;gt;] do_syscall_64+0x152/0x250
[&amp;lt;0&amp;gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53&lt;/p&gt;
&lt;p&gt;In addition the dmesg was filled wit…&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;memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done&lt;/p&gt;
&lt;p&gt;At Meta, we are seeing instances where an OOM killed job is stuck in the
exit path for several hours.  In one particular case, the job was stuck
for more than 8 hours and I had to manually remove the memory.max limits
to allow the process to exit.&lt;/p&gt;
&lt;p&gt;The job was a single process job and had ~55 GiB memory.max and zswap
enabled.  It had almost 0 anon in memory and ~111 GiB in zswap compressed
to ~51 GiB zswap pool (i.e.  almost all of memory.current was zswap). 
Nothing was left on the LRUs to reclaim.&lt;/p&gt;
&lt;p&gt;On further inspection, I observed ~20k threads of that process stuck with
the following stack:&lt;/p&gt;
&lt;p&gt;[&amp;lt;0&amp;gt;] mem_cgroup_out_of_memory+0x4e/0xa0
[&amp;lt;0&amp;gt;] charge_memcg+0x8bf/0x990
[&amp;lt;0&amp;gt;] mem_cgroup_swapin_charge_folio+0x4e/0x80
[&amp;lt;0&amp;gt;] __read_swap_cache_async+0x10c/0x260
[&amp;lt;0&amp;gt;] swapin_readahead+0x116/0x3f0
[&amp;lt;0&amp;gt;] do_swap_page+0x13c/0x1ce0
[&amp;lt;0&amp;gt;] handle_mm_fault+0x61d/0x11f0
[&amp;lt;0&amp;gt;] do_user_addr_fault+0x3e7/0x6d0
[&amp;lt;0&amp;gt;] exc_page_fault+0x8f/0x110
[&amp;lt;0&amp;gt;] asm_exc_page_fault+0x22/0x30
[&amp;lt;0&amp;gt;] __get_user_8+0x14/0x20
[&amp;lt;0&amp;gt;] futex_cleanup+0x27/0x1c0
[&amp;lt;0&amp;gt;] futex_exit_release+0x47/0x60
[&amp;lt;0&amp;gt;] do_exit+0x107/0x940
[&amp;lt;0&amp;gt;] do_group_exit+0x81/0xa0
[&amp;lt;0&amp;gt;] get_signal+0x2b1/0x6e0
[&amp;lt;0&amp;gt;] arch_do_signal_or_restart+0x1a/0x1c0
[&amp;lt;0&amp;gt;] exit_to_user_mode_loop+0xa8/0x1c0
[&amp;lt;0&amp;gt;] do_syscall_64+0x152/0x250
[&amp;lt;0&amp;gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53&lt;/p&gt;
&lt;p&gt;In addition the dmesg was filled wit…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-vxm3-j3p3-g54x</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-93241</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-93241</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done At Meta, we are seeing instances where an OOM killed job is stuck in the exit path for several hours.  In one particular case, the job was stuck for more than 8 hours and I had to manually remove the memory.max limits to allow the process to exit. The job was a single process job and had ~55 GiB memory.max and zswap enabled.  It had almost 0 anon in memory and ~111 GiB in zswap compressed to ~51 GiB zswap pool (i.e.  almost all of memory.current was zswap). Nothing was left on the LRUs to reclaim. On further inspection, I observed ~20k threads of that process stuck with the following stack: [&amp;lt;0&amp;gt;] mem_cgroup_out_of_memory+0x4e/0xa0 [&amp;lt;0&amp;gt;] charge_memcg+0x8bf/0x990 [&amp;lt;0&amp;gt;] mem_cgroup_swapin_charge_folio+0x4e/0x80 [&amp;lt;0&amp;gt;] __read_swap_cache_async+0x10c/0x260 [&amp;lt;0&amp;gt;] swapin_readahead+0x116/0x3f0 [&amp;lt;0&amp;gt;] do_swap_page+0x13c/0x1ce0 [&amp;lt;0&amp;gt;] handle_mm_fault+0x61d/0x11f0 [&amp;lt;0&amp;gt;] do_user_addr_fault+0x3e7/0x6d0 [&amp;lt;0&amp;gt;] exc_page_fault+0x8f/0x110 [&amp;lt;0&amp;gt;] asm_exc_page_fault+0x22/0x30 [&amp;lt;0&amp;gt;] __get_user_8+0x14/0x20 [&amp;lt;0&amp;gt;] futex_cleanup+0x27/0x1c0 [&amp;lt;0&amp;gt;] futex_exit_release+0x47/0x60 [&amp;lt;0&amp;gt;] do_exit+0x107/0x940 [&amp;lt;0&amp;gt;] do_group_exit+0x81/0xa0 [&amp;lt;0&amp;gt;] get_signal+0x2b1/0x6e0 [&amp;lt;0&amp;gt;] arch_do_signal_or_restart+0x1a/0x1c0 [&amp;lt;0&amp;gt;] exit_to_user_mode_loop+0xa8/0x1c0 [&amp;lt;0&amp;gt;] do_syscall_64+0x152/0x250 [&amp;lt;0&amp;gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53 In addition the dmesg was filled with &amp;#34;Out…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done At Meta, we are seeing instances where an OOM killed job is stuck in the exit path for several hours.  In one particular case, the job was stuck for more than 8 hours and I had to manually remove the memory.max limits to allow the process to exit. The job was a single process job and had ~55 GiB memory.max and zswap enabled.  It had almost 0 anon in memory and ~111 GiB in zswap compressed to ~51 GiB zswap pool (i.e.  almost all of memory.current was zswap). Nothing was left on the LRUs to reclaim. On further inspection, I observed ~20k threads of that process stuck with the following stack: [&amp;lt;0&amp;gt;] mem_cgroup_out_of_memory+0x4e/0xa0 [&amp;lt;0&amp;gt;] charge_memcg+0x8bf/0x990 [&amp;lt;0&amp;gt;] mem_cgroup_swapin_charge_folio+0x4e/0x80 [&amp;lt;0&amp;gt;] __read_swap_cache_async+0x10c/0x260 [&amp;lt;0&amp;gt;] swapin_readahead+0x116/0x3f0 [&amp;lt;0&amp;gt;] do_swap_page+0x13c/0x1ce0 [&amp;lt;0&amp;gt;] handle_mm_fault+0x61d/0x11f0 [&amp;lt;0&amp;gt;] do_user_addr_fault+0x3e7/0x6d0 [&amp;lt;0&amp;gt;] exc_page_fault+0x8f/0x110 [&amp;lt;0&amp;gt;] asm_exc_page_fault+0x22/0x30 [&amp;lt;0&amp;gt;] __get_user_8+0x14/0x20 [&amp;lt;0&amp;gt;] futex_cleanup+0x27/0x1c0 [&amp;lt;0&amp;gt;] futex_exit_release+0x47/0x60 [&amp;lt;0&amp;gt;] do_exit+0x107/0x940 [&amp;lt;0&amp;gt;] do_group_exit+0x81/0xa0 [&amp;lt;0&amp;gt;] get_signal+0x2b1/0x6e0 [&amp;lt;0&amp;gt;] arch_do_signal_or_restart+0x1a/0x1c0 [&amp;lt;0&amp;gt;] exit_to_user_mode_loop+0xa8/0x1c0 [&amp;lt;0&amp;gt;] do_syscall_64+0x152/0x250 [&amp;lt;0&amp;gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53 In addition the dmesg was filled with &amp;#34;Out…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-93241</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3579 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</guid>
    </item>
  </channel>
</rss>
