<?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-10-26T17:35:32.195316+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/fkie_cve-2026-98869</id>
    <title>fkie_cve-2026-98869</title>
    <updated>2026-10-26T17:35:32.226737+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>bpf: Infer zext_dst based on static register liveness analysis</p>
<p>As reported in the thread [1], the verifier's 32-bit operations zero
extension logic is broken. This logic is responsible for correct
semantics of 32-bit operations on s390 architecture.</p>
<p>According to BPF semantics, operation `w1 += 1` is supposed to zero
extend the upper half of the register `r1`. On s390 the JIT relies on
the verifier emitting explicit zero extension before such operations.</p>
<p>The verifier attempts to minimize the amount of zero extensions
inserted by tracking whether upper halves of the 64-bit registers are
ever used. Previously such tracking worked as follows:</p>
<p>- bpf_reg_state-&gt;subreg_def field was set by do_check_insn()
  for each operation defining lower but not the upper halves
  of the register.
- Whenever an operation reading the whole register was verified,
  the verifier checked register's subreg_def and set
  bpf_insn_aux_data-&gt;zext_dst flag as true via a call to
  mark_insn_zext() function.
- After the verification was complete, a special pass
  bpf_opt_subreg_zext_lo32_rnd_hi32() extended 32-bit operations
  with bpf_insn_aux_data-&gt;zext_dst set as true by adding
  explicit zero extension.</p>
<p>Note that the logic above relies on bpf_reg_state-&gt;subreg_def,
which is a property of a current verifier state.
Before the commit [2] two additional steps happened:</p>
<p>- The verifier tracked upper and lower register halves' liveness…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-98869"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-m2xx-ffwm-822c</id>
    <title>GHSA-m2xx-ffwm-822c</title>
    <updated>2026-10-26T17:35:32.226833+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>bpf: Infer zext_dst based on static register liveness analysis</p>
<p>As reported in the thread [1], the verifier's 32-bit operations zero
extension logic is broken. This logic is responsible for correct
semantics of 32-bit operations on s390 architecture.</p>
<p>According to BPF semantics, operation `w1 += 1` is supposed to zero
extend the upper half of the register `r1`. On s390 the JIT relies on
the verifier emitting explicit zero extension before such operations.</p>
<p>The verifier attempts to minimize the amount of zero extensions
inserted by tracking whether upper halves of the 64-bit registers are
ever used. Previously such tracking worked as follows:</p>
<p>- bpf_reg_state-&gt;subreg_def field was set by do_check_insn()
  for each operation defining lower but not the upper halves
  of the register.
- Whenever an operation reading the whole register was verified,
  the verifier checked register's subreg_def and set
  bpf_insn_aux_data-&gt;zext_dst flag as true via a call to
  mark_insn_zext() function.
- After the verification was complete, a special pass
  bpf_opt_subreg_zext_lo32_rnd_hi32() extended 32-bit operations
  with bpf_insn_aux_data-&gt;zext_dst set as true by adding
  explicit zero extension.</p>
<p>Note that the logic above relies on bpf_reg_state-&gt;subreg_def,
which is a property of a current verifier state.
Before the commit [2] two additional steps happened:</p>
<p>- The verifier tracked upper and lower register halves' liveness…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-m2xx-ffwm-822c"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ubuntu-cve-2026-98869</id>
    <title>UBUNTU-CVE-2026-98869</title>
    <updated>2026-10-26T17:35:32.226874+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 118 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: bpf: Infer zext_dst based on static register liveness analysis As reported in the thread [1], the verifier's 32-bit operations zero extension logic is broken. This logic is responsible for correct semantics of 32-bit operations on s390 architecture. According to BPF semantics, operation `w1 += 1` is supposed to zero extend the upper half of the register `r1`. On s390 the JIT relies on the verifier emitting explicit zero extension before such operations. The verifier attempts to minimize the amount of zero extensions inserted by tracking whether upper halves of the 64-bit registers are ever used. Previously such tracking worked as follows: - bpf_reg_state-&gt;subreg_def field was set by do_check_insn()   for each operation defining lower but not the upper halves   of the register. - Whenever an operation reading the whole register was verified,   the verifier checked register's subreg_def and set   bpf_insn_aux_data-&gt;zext_dst flag as true via a call to   mark_insn_zext() function. - After the verification was complete, a special pass   bpf_opt_subreg_zext_lo32_rnd_hi32() extended 32-bit operations   with bpf_insn_aux_data-&gt;zext_dst set as true by adding   explicit zero extension. Note that the logic above relies on bpf_reg_state-&gt;subreg_def, which is a property of a current verifier state. Before the commit [2] two additional steps happened: - The verifier tracked upper and lower register halves' liveness as   f…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ubuntu-cve-2026-98869"/>
  </entry>
</feed>
