<?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-12T14:08:35.283918+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-99236</id>
    <title>fkie_cve-2026-99236</title>
    <updated>2026-11-12T14:08:35.292371+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>tracing: Reject incomplete event filter expressions</p>
<p>A non-empty expression normally finishes in predicate_parse()'s inner
loop, which resolves the pending logical operators before jumping to
finalization. If the input ends after an operator, possibly followed by
unary '!' tokens, the outer loop instead falls through with unresolved
operator state.</p>
<p>For example, "common_pid == 1 || common_pid == 2 &amp;&amp;" leaves
prog[0].target equal to -1. The second pass then reads prog[-1] before
the forward-jump check can reject it. Depending on adjacent slab
contents, it can also copy an out-of-bounds word into a branch target
that passes the forward-only check. A self-targeted perf tracepoint
counting event can reach this path through PERF_EVENT_IOC_SET_FILTER.</p>
<p>Reject the outer-loop fallthrough when a predicate has already been
parsed. This ensures that non-empty expressions only reach finalization
after the inner loop has resolved their operators. Keep the existing
no-filter error for input that has no predicates. Add a regression test
for trailing logical operators and unary negations.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-99236"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-45x7-jj5h-2j9x</id>
    <title>GHSA-45x7-jj5h-2j9x</title>
    <updated>2026-11-12T14:08:35.292447+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>tracing: Reject incomplete event filter expressions</p>
<p>A non-empty expression normally finishes in predicate_parse()'s inner
loop, which resolves the pending logical operators before jumping to
finalization. If the input ends after an operator, possibly followed by
unary '!' tokens, the outer loop instead falls through with unresolved
operator state.</p>
<p>For example, "common_pid == 1 || common_pid == 2 &amp;&amp;" leaves
prog[0].target equal to -1. The second pass then reads prog[-1] before
the forward-jump check can reject it. Depending on adjacent slab
contents, it can also copy an out-of-bounds word into a branch target
that passes the forward-only check. A self-targeted perf tracepoint
counting event can reach this path through PERF_EVENT_IOC_SET_FILTER.</p>
<p>Reject the outer-loop fallthrough when a predicate has already been
parsed. This ensures that non-empty expressions only reach finalization
after the inner loop has resolved their operators. Keep the existing
no-filter error for input that has no predicates. Add a regression test
for trailing logical operators and unary negations.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-45x7-jj5h-2j9x"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/msrc_cve-2026-99236</id>
    <title>msrc_CVE-2026-99236 — tracing: Reject incomplete event filter expressions</title>
    <updated>2026-11-12T14:08:35.292477+00:00</updated>
    <content>msrc_CVE-2026-99236</content>
    <link href="https://db.gcve.eu/vuln/msrc_cve-2026-99236"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/oesa-2026-4810</id>
    <title>OESA-2026-4810 — kernel security update</title>
    <updated>2026-11-12T14:08:35.292498+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: kernel</p>
<p>The Linux Kernel, the operating system core itself.

Security Fix(es):</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>wifi: brcmsmac: Fix dma_free_coherent() size</p>
<p>dma_alloc_consistent() may change the size to align it. The new size is
saved in alloced.</p>
<p>Change the free size to match the allocation size.(CVE-2026-31661)</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>drm/amd/display: Validate GPIO pin LUT table size before iterating</p>
<p>[Why&amp;amp;How]
The GPIO pin table parsers in get_gpio_i2c_info() and
bios_parser_get_gpio_pin_info() derive an element count from the VBIOS
table_header.structuresize field, then iterate over gpio_pin[] entries.
However, GET_IMAGE() only validates that the table header itself fits
within the BIOS image. If the VBIOS reports a structuresize larger than
the actual mapped data, the loop reads past the end of the BIOS image,
causing an out-of-bounds read.</p>
<p>Fix this by calling bios_get_image() to validate that the full claimed
structuresize is accessible within the BIOS image before entering the
loop in both functions.</p>
<p>(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)(CVE-2026-64097)</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>usbip: vudc: fix NULL deref in vep_dequeue()</p>
<p>vep_alloc_request() wasn&amp;apos;t initializing vrequest-&amp;gt;udc, so cancellations
on the FunctionFS AIO path were arriving in vep_dequeue without a valid
UDC reference.</p>
<p>Since vrequest-&amp;gt;udc…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/oesa-2026-4810"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/opensuse-su-2026:12497-1</id>
    <title>openSUSE-SU-2026:12497-1 — kernel-devel-7.3.3-1.1 on GA media</title>
    <updated>2026-11-12T14:08:35.292667+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>kernel-devel-7.3.3-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/opensuse-su-2026:12497-1"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ubuntu-cve-2026-99236</id>
    <title>UBUNTU-CVE-2026-99236</title>
    <updated>2026-11-12T14:08:35.292697+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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 230 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: tracing: Reject incomplete event filter expressions A non-empty expression normally finishes in predicate_parse()'s inner loop, which resolves the pending logical operators before jumping to finalization. If the input ends after an operator, possibly followed by unary '!' tokens, the outer loop instead falls through with unresolved operator state. For example, "common_pid == 1 || common_pid == 2 &amp;&amp;" leaves prog[0].target equal to -1. The second pass then reads prog[-1] before the forward-jump check can reject it. Depending on adjacent slab contents, it can also copy an out-of-bounds word into a branch target that passes the forward-only check. A self-targeted perf tracepoint counting event can reach this path through PERF_EVENT_IOC_SET_FILTER. Reject the outer-loop fallthrough when a predicate has already been parsed. This ensures that non-empty expressions only reach finalization after the inner loop has resolved their operators. Keep the existing no-filter error for input that has no predicates. Add a regression test for trailing logical operators and unary negations.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ubuntu-cve-2026-99236"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/wid-sec-w-2026-4302</id>
    <title>WID-SEC-W-2026-4302 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
    <updated>2026-11-12T14:08:35.292988+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Auslösung eines Denial-of-Service-Angriffs, die Manipulation oder Offenlegung von Daten, die Ausführung von beliebigem Code, die Erlangung erweiterter Berechtigungen oder die Umgehung von Sicherheitsmaßnahmen.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/wid-sec-w-2026-4302"/>
  </entry>
</feed>
