<?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 19:30:50 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-98151</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-98151</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic&lt;/p&gt;
&lt;p&gt;Take the following unprivileged program as an example:&lt;/p&gt;
&lt;p&gt;r0 = bpf_map_lookup_elem(...)	/* PTR_TO_MAP_VALUE, offset 0 */
	...
	14: r0 += r1			/* r1 is a bounded scalar */
	15: r9 = r0&lt;/p&gt;
&lt;p&gt;Loading it triggers a verifier warning from reg_bounds_sanity_check():&lt;/p&gt;
&lt;p&gt;verifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out
	of sync with range bounds r64={.base=0x0, .size=0x0}
	r32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0)&lt;/p&gt;
&lt;p&gt;What happens:&lt;/p&gt;
&lt;p&gt;1. Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new
   offset is computed into dst_reg&amp;#39;s var_off and 32/64-bit ranges.&lt;/p&gt;
&lt;p&gt;2. Because pointer registers do not track 32-bit subregister bounds,
   __mark_reg32_unbounded() first sets r32 to the full range; r32 is
   re-derived from the offset at the end of the function by
   reg_bounds_sync().&lt;/p&gt;
&lt;p&gt;3. On the unprivileged path, sanitize_ptr_alu() is called and, via
   sanitize_speculative_path() -&amp;gt; push_stack(), snapshots the current
   register state and schedules the next instruction (insn 15) to be
   verified directly as a speculative path.&lt;/p&gt;
&lt;p&gt;4. That snapshot is taken between step 2 and the final reg_bounds_sync():
   at this point dst_reg&amp;#39;s var_off still holds the (const) original
   offset while r32 has just been blanked to the full range, i.e. the two
   are out of sync. When the speculative path later verifies insn 15
   (r9 = r0), th…&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;bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic&lt;/p&gt;
&lt;p&gt;Take the following unprivileged program as an example:&lt;/p&gt;
&lt;p&gt;r0 = bpf_map_lookup_elem(...)	/* PTR_TO_MAP_VALUE, offset 0 */
	...
	14: r0 += r1			/* r1 is a bounded scalar */
	15: r9 = r0&lt;/p&gt;
&lt;p&gt;Loading it triggers a verifier warning from reg_bounds_sanity_check():&lt;/p&gt;
&lt;p&gt;verifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out
	of sync with range bounds r64={.base=0x0, .size=0x0}
	r32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0)&lt;/p&gt;
&lt;p&gt;What happens:&lt;/p&gt;
&lt;p&gt;1. Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new
   offset is computed into dst_reg&amp;#39;s var_off and 32/64-bit ranges.&lt;/p&gt;
&lt;p&gt;2. Because pointer registers do not track 32-bit subregister bounds,
   __mark_reg32_unbounded() first sets r32 to the full range; r32 is
   re-derived from the offset at the end of the function by
   reg_bounds_sync().&lt;/p&gt;
&lt;p&gt;3. On the unprivileged path, sanitize_ptr_alu() is called and, via
   sanitize_speculative_path() -&amp;gt; push_stack(), snapshots the current
   register state and schedules the next instruction (insn 15) to be
   verified directly as a speculative path.&lt;/p&gt;
&lt;p&gt;4. That snapshot is taken between step 2 and the final reg_bounds_sync():
   at this point dst_reg&amp;#39;s var_off still holds the (const) original
   offset while r32 has just been blanked to the full range, i.e. the two
   are out of sync. When the speculative path later verifies insn 15
   (r9 = r0), th…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-98151</guid>
    </item>
    <item>
      <title>GHSA-6969-2pr3-9qx5</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-6969-2pr3-9qx5</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic&lt;/p&gt;
&lt;p&gt;Take the following unprivileged program as an example:&lt;/p&gt;
&lt;p&gt;r0 = bpf_map_lookup_elem(...)	/* PTR_TO_MAP_VALUE, offset 0 */
	...
	14: r0 += r1			/* r1 is a bounded scalar */
	15: r9 = r0&lt;/p&gt;
&lt;p&gt;Loading it triggers a verifier warning from reg_bounds_sanity_check():&lt;/p&gt;
&lt;p&gt;verifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out
	of sync with range bounds r64={.base=0x0, .size=0x0}
	r32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0)&lt;/p&gt;
&lt;p&gt;What happens:&lt;/p&gt;
&lt;p&gt;1. Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new
   offset is computed into dst_reg&amp;#39;s var_off and 32/64-bit ranges.&lt;/p&gt;
&lt;p&gt;2. Because pointer registers do not track 32-bit subregister bounds,
   __mark_reg32_unbounded() first sets r32 to the full range; r32 is
   re-derived from the offset at the end of the function by
   reg_bounds_sync().&lt;/p&gt;
&lt;p&gt;3. On the unprivileged path, sanitize_ptr_alu() is called and, via
   sanitize_speculative_path() -&amp;gt; push_stack(), snapshots the current
   register state and schedules the next instruction (insn 15) to be
   verified directly as a speculative path.&lt;/p&gt;
&lt;p&gt;4. That snapshot is taken between step 2 and the final reg_bounds_sync():
   at this point dst_reg&amp;#39;s var_off still holds the (const) original
   offset while r32 has just been blanked to the full range, i.e. the two
   are out of sync. When the speculative path later verifies insn 15
   (r9 = r0), th…&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;bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic&lt;/p&gt;
&lt;p&gt;Take the following unprivileged program as an example:&lt;/p&gt;
&lt;p&gt;r0 = bpf_map_lookup_elem(...)	/* PTR_TO_MAP_VALUE, offset 0 */
	...
	14: r0 += r1			/* r1 is a bounded scalar */
	15: r9 = r0&lt;/p&gt;
&lt;p&gt;Loading it triggers a verifier warning from reg_bounds_sanity_check():&lt;/p&gt;
&lt;p&gt;verifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out
	of sync with range bounds r64={.base=0x0, .size=0x0}
	r32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0)&lt;/p&gt;
&lt;p&gt;What happens:&lt;/p&gt;
&lt;p&gt;1. Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new
   offset is computed into dst_reg&amp;#39;s var_off and 32/64-bit ranges.&lt;/p&gt;
&lt;p&gt;2. Because pointer registers do not track 32-bit subregister bounds,
   __mark_reg32_unbounded() first sets r32 to the full range; r32 is
   re-derived from the offset at the end of the function by
   reg_bounds_sync().&lt;/p&gt;
&lt;p&gt;3. On the unprivileged path, sanitize_ptr_alu() is called and, via
   sanitize_speculative_path() -&amp;gt; push_stack(), snapshots the current
   register state and schedules the next instruction (insn 15) to be
   verified directly as a speculative path.&lt;/p&gt;
&lt;p&gt;4. That snapshot is taken between step 2 and the final reg_bounds_sync():
   at this point dst_reg&amp;#39;s var_off still holds the (const) original
   offset while r32 has just been blanked to the full range, i.e. the two
   are out of sync. When the speculative path later verifies insn 15
   (r9 = r0), th…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-6969-2pr3-9qx5</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-98151</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-98151</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: bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic Take the following unprivileged program as an example: 	r0 = bpf_map_lookup_elem(...)	/* PTR_TO_MAP_VALUE, offset 0 */ 	... 	14: r0 += r1			/* r1 is a bounded scalar */ 	15: r9 = r0 Loading it triggers a verifier warning from reg_bounds_sanity_check(): 	verifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out 	of sync with range bounds r64={.base=0x0, .size=0x0} 	r32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0) What happens: 1. Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new    offset is computed into dst_reg&amp;#39;s var_off and 32/64-bit ranges. 2. Because pointer registers do not track 32-bit subregister bounds,    __mark_reg32_unbounded() first sets r32 to the full range; r32 is    re-derived from the offset at the end of the function by    reg_bounds_sync(). 3. On the unprivileged path, sanitize_ptr_alu() is called and, via    sanitize_speculative_path() -&amp;gt; push_stack(), snapshots the current    register state and schedules the next instruction (insn 15) to be    verified directly as a speculative path. 4. That snapshot is taken between step 2 and the final reg_bounds_sync():    at this point dst_reg&amp;#39;s var_off still holds the (const) original    offset while r32 has just been blanked to the full range, i.e. the two    are out of sync. When the speculative path later verifies insn 15    (r9 = r0), the inconsis…&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: bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic Take the following unprivileged program as an example: 	r0 = bpf_map_lookup_elem(...)	/* PTR_TO_MAP_VALUE, offset 0 */ 	... 	14: r0 += r1			/* r1 is a bounded scalar */ 	15: r9 = r0 Loading it triggers a verifier warning from reg_bounds_sanity_check(): 	verifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out 	of sync with range bounds r64={.base=0x0, .size=0x0} 	r32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0) What happens: 1. Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new    offset is computed into dst_reg&amp;#39;s var_off and 32/64-bit ranges. 2. Because pointer registers do not track 32-bit subregister bounds,    __mark_reg32_unbounded() first sets r32 to the full range; r32 is    re-derived from the offset at the end of the function by    reg_bounds_sync(). 3. On the unprivileged path, sanitize_ptr_alu() is called and, via    sanitize_speculative_path() -&amp;gt; push_stack(), snapshots the current    register state and schedules the next instruction (insn 15) to be    verified directly as a speculative path. 4. That snapshot is taken between step 2 and the final reg_bounds_sync():    at this point dst_reg&amp;#39;s var_off still holds the (const) original    offset while r32 has just been blanked to the full range, i.e. the two    are out of sync. When the speculative path later verifies insn 15    (r9 = r0), the inconsis…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-98151</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>
