<?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://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T16:25:25.544688+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" 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://vulnerability.circl.lu/vuln/bell-cve-2026-89915</id>
    <title>BELL-CVE-2026-89915</title>
    <updated>2026-10-02T16:25:26.612942+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/bell-cve-2026-89915"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-89915</id>
    <title>fkie_cve-2026-89915</title>
    <updated>2026-10-02T16:25:26.613041+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>KVM: arm64: Remove VM-wide VNCR mapping counter</p>
<p>The global VNCR mapping counter is used to decide whether an L1
provided VNCR page is mapped in L0 on any CPU at the point of
dealing with a TLB invalidation. It is incremented when a mapping
is made in the fixmap, and decremented when unmapped.</p>
<p>As it turns out, this tracking has several flaws:</p>
<p>- we are trying to invalidate TLBs, and the mapping is only an
  opportunistic consequence of the TLB. Checking this counter to
  decide whether a TLB needs to be invalidated may result in missed
  invalidations.</p>
<p>- an L1 vcpu invalidating its own TLB (a very likely case) will not
  succeed in invalidating the VNCR pseudo TLB because that page is
  not mapped in L0 at this stage.</p>
<p>Given that this tracking fails at delivering the minimum guarantees
that are required and is only a performance optimisation, remove it
completely.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-89915"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-crqv-c33h-f779</id>
    <title>GHSA-crqv-c33h-f779</title>
    <updated>2026-10-02T16:25:26.613123+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>KVM: arm64: Remove VM-wide VNCR mapping counter</p>
<p>The global VNCR mapping counter is used to decide whether an L1
provided VNCR page is mapped in L0 on any CPU at the point of
dealing with a TLB invalidation. It is incremented when a mapping
is made in the fixmap, and decremented when unmapped.</p>
<p>As it turns out, this tracking has several flaws:</p>
<p>- we are trying to invalidate TLBs, and the mapping is only an
  opportunistic consequence of the TLB. Checking this counter to
  decide whether a TLB needs to be invalidated may result in missed
  invalidations.</p>
<p>- an L1 vcpu invalidating its own TLB (a very likely case) will not
  succeed in invalidating the VNCR pseudo TLB because that page is
  not mapped in L0 at this stage.</p>
<p>Given that this tracking fails at delivering the minimum guarantees
that are required and is only a performance optimisation, remove it
completely.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-crqv-c33h-f779"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/opensuse-su-2026:11880-1</id>
    <title>openSUSE-SU-2026:11880-1 — kernel-devel-7.2.7-1.1 on GA media</title>
    <updated>2026-10-02T16:25:26.613174+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>kernel-devel-7.2.7-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/opensuse-su-2026:11880-1"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-89915</id>
    <title>UBUNTU-CVE-2026-89915</title>
    <updated>2026-10-02T16:25:26.613989+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> 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 120 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Remove VM-wide VNCR mapping counter The global VNCR mapping counter is used to decide whether an L1 provided VNCR page is mapped in L0 on any CPU at the point of dealing with a TLB invalidation. It is incremented when a mapping is made in the fixmap, and decremented when unmapped. As it turns out, this tracking has several flaws: - we are trying to invalidate TLBs, and the mapping is only an   opportunistic consequence of the TLB. Checking this counter to   decide whether a TLB needs to be invalidated may result in missed   invalidations. - an L1 vcpu invalidating its own TLB (a very likely case) will not   succeed in invalidating the VNCR pseudo TLB because that page is   not mapped in L0 at this stage. Given that this tracking fails at delivering the minimum guarantees that are required and is only a performance optimisation, remove it completely.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-89915"/>
  </entry>
</feed>
