<?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-12T11:05:29.079724+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-43365</id>
    <title>CVE-2026-43365 — xfs: fix undersized l_iclog_roundoff values</title>
    <updated>2026-10-12T11:05:29.221594+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>xfs: fix undersized l_iclog_roundoff values</p>
<p>If the superblock doesn't list a log stripe unit, we set the incore log
roundoff value to 512.  This leads to corrupt logs and unmountable
filesystems in generic/617 on a disk with 4k physical sectors...</p>
<p>XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c
XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197.
XFS (sda1): failed to locate log tail
XFS (sda1): log mount/recovery failed: error -74
XFS (sda1): log mount failed
XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c
XFS (sda1): Ending clean mount</p>
<p>...on the current xfsprogs for-next which has a broken mkfs.  xfs_info
shows this...</p>
<p>meta-data=/dev/sda1              isize=512    agcount=4, agsize=644992 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=1
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=1
         =                       exchange=1   metadir=1
data     =                       bsize=4096   blocks=2579968, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=1
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=4096  sunit=0 blks, lazy-co…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-43365"/>
  </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-12T11:05:29.221688+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>
