<?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-17T20:39:36.083840+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-2026-43023</id>
    <title>CVE-2026-43023 — Bluetooth: SCO: fix race conditions in sco_sock_connect()</title>
    <updated>2026-10-17T20:39:36.321221+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>Bluetooth: SCO: fix race conditions in sco_sock_connect()</p>
<p>sco_sock_connect() checks sk_state and sk_type without holding
the socket lock. Two concurrent connect() syscalls on the same
socket can both pass the check and enter sco_connect(), leading
to use-after-free.</p>
<p>The buggy scenario involves three participants and was confirmed
with additional logging instrumentation:</p>
<p>Thread A (connect):    HCI disconnect:      Thread B (connect):</p>
<p>sco_sock_connect(sk)                        sco_sock_connect(sk)
  sk_state==BT_OPEN                           sk_state==BT_OPEN
  (pass, no lock)                             (pass, no lock)
  sco_connect(sk):                            sco_connect(sk):
    hci_dev_lock                                hci_dev_lock
    hci_connect_sco                               &lt;- blocked
      -&gt; hcon1
    sco_conn_add-&gt;conn1
    lock_sock(sk)
    sco_chan_add:
      conn1-&gt;sk = sk
      sk-&gt;conn = conn1
    sk_state=BT_CONNECT
    release_sock
    hci_dev_unlock
                           hci_dev_lock
                           sco_conn_del:
                             lock_sock(sk)
                             sco_chan_del:
                               sk-&gt;conn=NULL
                               conn1-&gt;sk=NULL
                               sk_state=
                                 BT_CLOSED
                               SOCK_ZAPPED
                             release_sock…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-43023"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/lsn-0122-1</id>
    <title>LSN-0122-1 — Kernel Live Patch Security Notice</title>
    <updated>2026-10-17T20:39:36.321413+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 25 more</p>
<p>In the Linux kernel, the following vulnerability has been
resolved: fs: dlm: fix use after free in midcomms commit While working on
processing dlm message in softirq context I experienced the following KASAN
use-after-free warning: .</p>
<p>In the Linux kernel, the following vulnerability has been
resolved: wifi: brcmfmac: Fix oops due to NULL pointer dereference in
brcmf_sdiod_sglist_rw() 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>In the Linux kernel, the following vulnerability has been
resolved: padata: fix UAF in padata_reorder A bug was found when run ltp
test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read
of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0
PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+
Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: &lt;TASK&gt;
dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0
print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0
padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0
process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling
'padata_find_next' in the 'padata_reorder' function, this issue could be
reproduced easily with ltp test (pcrypt_aead01).</p>
<p>In the Linux kernel, the following vulnerability has been
resolved: geneve: Fix use-after-free in geneve_find_de…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/lsn-0122-1"/>
  </entry>
</feed>
