<?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://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-11-02T23:08:35.079570+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" 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://db.gcve.eu/vuln/certfr-2026-avi-1375</id>
    <title>certfr-2026-avi-1375 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Certaines d'entre elles permettent à…</title>
    <updated>2026-11-02T23:08:35.115647+00:00</updated>
    <content>certfr-2026-avi-1375</content>
    <link href="https://db.gcve.eu/vuln/certfr-2026-avi-1375"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-98507</id>
    <title>fkie_cve-2026-98507</title>
    <updated>2026-11-02T23:08:35.115703+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>mm/rmap: fix missing barrier between anon_vma init and vma-&gt;anon_vma publish</p>
<p>On arm64 server, we find that a task trying to grab the anon_vma lock
triggers hungtask.</p>
<p>INFO: task main:2354726 blocked for more than 120 seconds.
      Tainted: G            E     5.10.0-0021.aarch64 #1
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:main            state:D stack:    0 pid:2354726 ppid:2350673 flags:0x00000a01
Call trace:
 __switch_to+0x7c/0xbc
 __schedule+0x3b4/0x8a0
 schedule+0x50/0xe0
 rwsem_down_write_slowpath+0x3cc/0x6cc
 down_write+0x60/0x260
 __anon_vma_prepare+0x6c/0x210
 do_anonymous_page+0x258/0x660
 handle_pte_fault+0x188/0x214
 __handle_mm_fault+0x1b0/0x380
 handle_mm_fault+0xf4/0x284
 do_page_fault+0x19c/0x494
 do_translation_fault+0xcc/0xf8
 do_mem_abort+0x48/0xac
 el0_da+0x44/0x80
 el0_sync_handler+0x88/0xb4
 el0_sync+0x160/0x180</p>
<p>After analyzing the vmcore, we found the anon_vma-&gt;root-&gt;rwsem.count is
-1.  There is another anon_vma whose anon_vma-&gt;root-&gt;rwsem.count is 1, the
anon_vma-&gt;root-&gt;rwsem.owner shows the lock is held, but the stack of the
task shows the task doesn't hold the anon_vma lock.</p>
<p>After adding more debugging info, we found __anon_vma_prepare() reuses
anon_vma and triggers the UAF of anon_vma-&gt;root due to missing memory
barrier, leading to locking and unlocking two different anon_vma-&gt;root,
thus leading to an anon_vma will never be unlocked, and ano…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-98507"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-jr3f-x4p8-9x32</id>
    <title>GHSA-jr3f-x4p8-9x32</title>
    <updated>2026-11-02T23:08:35.115781+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>mm/rmap: fix missing barrier between anon_vma init and vma-&gt;anon_vma publish</p>
<p>On arm64 server, we find that a task trying to grab the anon_vma lock
triggers hungtask.</p>
<p>INFO: task main:2354726 blocked for more than 120 seconds.
      Tainted: G            E     5.10.0-0021.aarch64 #1
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:main            state:D stack:    0 pid:2354726 ppid:2350673 flags:0x00000a01
Call trace:
 __switch_to+0x7c/0xbc
 __schedule+0x3b4/0x8a0
 schedule+0x50/0xe0
 rwsem_down_write_slowpath+0x3cc/0x6cc
 down_write+0x60/0x260
 __anon_vma_prepare+0x6c/0x210
 do_anonymous_page+0x258/0x660
 handle_pte_fault+0x188/0x214
 __handle_mm_fault+0x1b0/0x380
 handle_mm_fault+0xf4/0x284
 do_page_fault+0x19c/0x494
 do_translation_fault+0xcc/0xf8
 do_mem_abort+0x48/0xac
 el0_da+0x44/0x80
 el0_sync_handler+0x88/0xb4
 el0_sync+0x160/0x180</p>
<p>After analyzing the vmcore, we found the anon_vma-&gt;root-&gt;rwsem.count is
-1.  There is another anon_vma whose anon_vma-&gt;root-&gt;rwsem.count is 1, the
anon_vma-&gt;root-&gt;rwsem.owner shows the lock is held, but the stack of the
task shows the task doesn't hold the anon_vma lock.</p>
<p>After adding more debugging info, we found __anon_vma_prepare() reuses
anon_vma and triggers the UAF of anon_vma-&gt;root due to missing memory
barrier, leading to locking and unlocking two different anon_vma-&gt;root,
thus leading to an anon_vma will never be unlocked, and ano…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-jr3f-x4p8-9x32"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/msrc_cve-2026-98507</id>
    <title>msrc_CVE-2026-98507 — mm/rmap: fix missing barrier between anon_vma init and vma-&gt;anon_vma publish</title>
    <updated>2026-11-02T23:08:35.115827+00:00</updated>
    <content>msrc_CVE-2026-98507</content>
    <link href="https://db.gcve.eu/vuln/msrc_cve-2026-98507"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ubuntu-cve-2026-98507</id>
    <title>UBUNTU-CVE-2026-98507</title>
    <updated>2026-11-02T23:08:35.115846+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 247 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: mm/rmap: fix missing barrier between anon_vma init and vma-&gt;anon_vma publish On arm64 server, we find that a task trying to grab the anon_vma lock triggers hungtask. INFO: task main:2354726 blocked for more than 120 seconds.       Tainted: G            E     5.10.0-0021.aarch64 #1 "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:main            state:D stack:    0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace:  __switch_to+0x7c/0xbc  __schedule+0x3b4/0x8a0  schedule+0x50/0xe0  rwsem_down_write_slowpath+0x3cc/0x6cc  down_write+0x60/0x260  __anon_vma_prepare+0x6c/0x210  do_anonymous_page+0x258/0x660  handle_pte_fault+0x188/0x214  __handle_mm_fault+0x1b0/0x380  handle_mm_fault+0xf4/0x284  do_page_fault+0x19c/0x494  do_translation_fault+0xcc/0xf8  do_mem_abort+0x48/0xac  el0_da+0x44/0x80  el0_sync_handler+0x88/0xb4  el0_sync+0x160/0x180 After analyzing the vmcore, we found the anon_vma-&gt;root-&gt;rwsem.count is -1.  There is another anon_vma whose anon_vma-&gt;root-&gt;rwsem.count is 1, the anon_vma-&gt;root-&gt;rwsem.owner shows the lock is held, but the stack of the task shows the task doesn't hold the anon_vma lock. After adding more debugging info, we found __anon_vma_prepare() reuses anon_vma and triggers the UAF of anon_vma-&gt;root due to missing memory barrier, leading to locking and unlocking two different anon_vma-&gt;root, thus leading to an anon_vma will never be unlocked, and another…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ubuntu-cve-2026-98507"/>
  </entry>
</feed>
