<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-12T12:06:40.291755+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/cve-2024-56593</id>
    <title>CVE-2024-56593 — wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()</title>
    <updated>2026-10-12T12:06:40.882944+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()</p>
<p>This patch fixes a NULL pointer dereference bug in brcmfmac that occurs
when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs
are sent from the pkt queue.</p>
<p>The problem is the number of entries in the pre-allocated sgtable, it is
nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) &gt;&gt; 4 + 1.
Given the default [rt]xglom_size=32 it's actually 35 which is too small.
Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB
is added for each original SKB if tailroom isn't enough to hold tail_pad.
At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"
in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return
NULL and this causes the oops.</p>
<p>The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle
the worst-case.
Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464
additional bytes of memory.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2024-56593"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/lsn-0112-1</id>
    <title>LSN-0112-1 — Kernel Live Patch Security Notice</title>
    <updated>2026-10-12T12:06:40.883038+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:Pro:18.04:LTS: linux-azure-4.15, Ubuntu:Pro:18.04:LTS: linux-gcp-4.15, Ubuntu:Pro:18.04:LTS: linux and 29 more</p>
<p>In the Linux kernel, the following vulnerability has been
resolved: nfsd: fix use-after-free due to delegation race A delegation
break could arrive as soon as we've called vfs_setlease. A delegation break
runs a callback which immediately (in nfsd4_cb_recall_prepare) adds the
delegation to del_recall_lru. If we then exit nfs4_set_delegation without
hashing the delegation, it will be freed as soon as the callback is done
with it, without ever being removed from del_recall_lru. Symptoms show up
later as use-after-free or list corruption warnings, usually in the
laundromat thread. I suspect aba2072f4523 'nfsd: grant read delegations to
clients holding writes' made this bug easier to hit, but I looked as far
back as v3.0 and it looks to me it already had the same problem. So I'm not
sure where the bug was introduced; it may have been there from the
beginning.)(CVE-2021-47506)</p>
<p>Jann Horn discovered that the watch_queue event notification subsystem in
the Linux kernel contained an out-of-bounds write vulnerability. A local
attacker could use this to cause a denial of service (system crash) or
escalate their privileges.)(CVE-2022-0995)</p>
<p>In the Linux kernel, the following vulnerability has been
resolved: net: atlantic: eliminate double free in error handling logic
Driver has a logic leak in ring data allocation/free, where aq_ring_free
could be called multiple times on same ring, if system is under stress and
got memory allocation error. Ring pointer was used as an indicator of
fail…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/lsn-0112-1"/>
  </entry>
</feed>
