<?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://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-07T23:50:12.576335+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" 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://vulnerability.circl.lu/vuln/bdu:2026-03679</id>
    <title>bdu:2026-03679</title>
    <updated>2026-10-07T23:50:13.075366+00:00</updated>
    <content>bdu:2026-03679</content>
    <link href="https://vulnerability.circl.lu/vuln/bdu:2026-03679"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2022-49425</id>
    <title>fkie_cve-2022-49425</title>
    <updated>2026-10-07T23:50:13.075432+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>f2fs: fix dereference of stale list iterator after loop body</p>
<p>The list iterator variable will be a bogus pointer if no break was hit.
Dereferencing it (cur-&gt;page in this case) could load an out-of-bounds/undefined
value making it unsafe to use that in the comparision to determine if the
specific element was found.</p>
<p>Since 'cur-&gt;page' *can* be out-ouf-bounds it cannot be guaranteed that
by chance (or intention of an attacker) it matches the value of 'page'
even though the correct element was not found.</p>
<p>This is fixed by using a separate list iterator variable for the loop
and only setting the original variable if a suitable element was found.
Then determing if the element was found is simply checking if the
variable is set.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2022-49425"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-2j82-ggvf-vjmx</id>
    <title>GHSA-2j82-ggvf-vjmx</title>
    <updated>2026-10-07T23:50:13.075508+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>f2fs: fix dereference of stale list iterator after loop body</p>
<p>The list iterator variable will be a bogus pointer if no break was hit.
Dereferencing it (cur-&gt;page in this case) could load an out-of-bounds/undefined
value making it unsafe to use that in the comparision to determine if the
specific element was found.</p>
<p>Since 'cur-&gt;page' *can* be out-ouf-bounds it cannot be guaranteed that
by chance (or intention of an attacker) it matches the value of 'page'
even though the correct element was not found.</p>
<p>This is fixed by using a separate list iterator variable for the loop
and only setting the original variable if a suitable element was found.
Then determing if the element was found is simply checking if the
variable is set.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-2j82-ggvf-vjmx"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/oesa-2025-1370</id>
    <title>OESA-2025-1370 — kernel security update</title>
    <updated>2026-10-07T23:50:13.075564+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> openEuler:20.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>ath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111</p>
<p>The bug was found during fuzzing. Stacktrace locates it in
ath5k_eeprom_convert_pcal_info_5111.
When none of the curve is selected in the loop, idx can go
up to AR5K_EEPROM_N_PD_CURVES. The line makes pd out of bound.
pd = &amp;amp;chinfo[pier].pd_curves[idx];</p>
<p>There are many OOB writes using pd later in the code. So I
added a sanity check for idx. Checks for other loops involving
AR5K_EEPROM_N_PD_CURVES are not needed as the loop index is not
used outside the loops.</p>
<p>The patch is NOT tested with real device.</p>
<p>The following is the fuzzing report</p>
<p>BUG: KASAN: slab-out-of-bounds in ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
Write of size 1 at addr ffff8880174a4d60 by task modprobe/214</p>
<p>CPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1
Call Trace:
 dump_stack+0x76/0xa0
 print_address_description.constprop.0+0x16/0x200
 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
 __kasan_report.cold+0x37/0x7c
 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
 kasan_report+0xe/0x20
 ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]
 ? apic_timer_interrupt+0xa/0x20
 ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k]
 ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k]
 ath5k_eeprom_init+0x2513/0x6290 [ath5k]
 ? ath5k_…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/oesa-2025-1370"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ubuntu-cve-2022-49425</id>
    <title>UBUNTU-CVE-2022-49425</title>
    <updated>2026-10-07T23:50:13.075816+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, 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, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux, Ubuntu:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.4 and 136 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: f2fs: fix dereference of stale list iterator after loop body The list iterator variable will be a bogus pointer if no break was hit. Dereferencing it (cur-&gt;page in this case) could load an out-of-bounds/undefined value making it unsafe to use that in the comparision to determine if the specific element was found. Since 'cur-&gt;page' *can* be out-ouf-bounds it cannot be guaranteed that by chance (or intention of an attacker) it matches the value of 'page' even though the correct element was not found. This is fixed by using a separate list iterator variable for the loop and only setting the original variable if a suitable element was found. Then determing if the element was found is simply checking if the variable is set.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ubuntu-cve-2022-49425"/>
  </entry>
</feed>
