<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 04 Oct 2026 16:48:20 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-07620</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-07620</link>
      <description>bdu:2024-07620</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-07620</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0779 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0779</link>
      <description>certfr-2024-avi-0779</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0779</guid>
    </item>
    <item>
      <title>EUVD-2026-310226</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-310226</link>
      <description>EUVD-2026-310226</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-310226</guid>
    </item>
    <item>
      <title>fkie_cve-2022-48898</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-48898</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer&lt;/p&gt;
&lt;p&gt;There are 3 possible interrupt sources are handled by DP controller,
HPDstatus, Controller state changes and Aux read/write transaction.
At every irq, DP controller have to check isr status of every interrupt
sources and service the interrupt if its isr status bits shows interrupts
are pending. There is potential race condition may happen at current aux
isr handler implementation since it is always complete dp_aux_cmd_fifo_tx()
even irq is not for aux read or write transaction. This may cause aux read
transaction return premature if host aux data read is in the middle of
waiting for sink to complete transferring data to host while irq happen.
This will cause host&amp;#39;s receiving buffer contains unexpected data. This
patch fixes this problem by checking aux isr and return immediately at
aux isr handler if there are no any isr status bits set.&lt;/p&gt;
&lt;p&gt;Current there is a bug report regrading eDP edid corruption happen during
system booting up. After lengthy debugging to found that VIDEO_READY
interrupt was continuously firing during system booting up which cause
dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data
from aux hardware buffer which is not yet contains complete data transfer
from sink. This cause edid corruption.&lt;/p&gt;
&lt;p&gt;Follows are the signature at kernel logs when problem happen,
EDID has corrupt header
panel-sim…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer&lt;/p&gt;
&lt;p&gt;There are 3 possible interrupt sources are handled by DP controller,
HPDstatus, Controller state changes and Aux read/write transaction.
At every irq, DP controller have to check isr status of every interrupt
sources and service the interrupt if its isr status bits shows interrupts
are pending. There is potential race condition may happen at current aux
isr handler implementation since it is always complete dp_aux_cmd_fifo_tx()
even irq is not for aux read or write transaction. This may cause aux read
transaction return premature if host aux data read is in the middle of
waiting for sink to complete transferring data to host while irq happen.
This will cause host&amp;#39;s receiving buffer contains unexpected data. This
patch fixes this problem by checking aux isr and return immediately at
aux isr handler if there are no any isr status bits set.&lt;/p&gt;
&lt;p&gt;Current there is a bug report regrading eDP edid corruption happen during
system booting up. After lengthy debugging to found that VIDEO_READY
interrupt was continuously firing during system booting up which cause
dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data
from aux hardware buffer which is not yet contains complete data transfer
from sink. This cause edid corruption.&lt;/p&gt;
&lt;p&gt;Follows are the signature at kernel logs when problem happen,
EDID has corrupt header
panel-sim…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-48898</guid>
    </item>
    <item>
      <title>GHSA-p4ww-qww8-jc5f</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-p4ww-qww8-jc5f</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer&lt;/p&gt;
&lt;p&gt;There are 3 possible interrupt sources are handled by DP controller,
HPDstatus, Controller state changes and Aux read/write transaction.
At every irq, DP controller have to check isr status of every interrupt
sources and service the interrupt if its isr status bits shows interrupts
are pending. There is potential race condition may happen at current aux
isr handler implementation since it is always complete dp_aux_cmd_fifo_tx()
even irq is not for aux read or write transaction. This may cause aux read
transaction return premature if host aux data read is in the middle of
waiting for sink to complete transferring data to host while irq happen.
This will cause host&amp;#39;s receiving buffer contains unexpected data. This
patch fixes this problem by checking aux isr and return immediately at
aux isr handler if there are no any isr status bits set.&lt;/p&gt;
&lt;p&gt;Current there is a bug report regrading eDP edid corruption happen during
system booting up. After lengthy debugging to found that VIDEO_READY
interrupt was continuously firing during system booting up which cause
dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data
from aux hardware buffer which is not yet contains complete data transfer
from sink. This cause edid corruption.&lt;/p&gt;
&lt;p&gt;Follows are the signature at kernel logs when problem happen,
EDID has corrupt header
panel-sim…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer&lt;/p&gt;
&lt;p&gt;There are 3 possible interrupt sources are handled by DP controller,
HPDstatus, Controller state changes and Aux read/write transaction.
At every irq, DP controller have to check isr status of every interrupt
sources and service the interrupt if its isr status bits shows interrupts
are pending. There is potential race condition may happen at current aux
isr handler implementation since it is always complete dp_aux_cmd_fifo_tx()
even irq is not for aux read or write transaction. This may cause aux read
transaction return premature if host aux data read is in the middle of
waiting for sink to complete transferring data to host while irq happen.
This will cause host&amp;#39;s receiving buffer contains unexpected data. This
patch fixes this problem by checking aux isr and return immediately at
aux isr handler if there are no any isr status bits set.&lt;/p&gt;
&lt;p&gt;Current there is a bug report regrading eDP edid corruption happen during
system booting up. After lengthy debugging to found that VIDEO_READY
interrupt was continuously firing during system booting up which cause
dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data
from aux hardware buffer which is not yet contains complete data transfer
from sink. This cause edid corruption.&lt;/p&gt;
&lt;p&gt;Follows are the signature at kernel logs when problem happen,
EDID has corrupt header
panel-sim…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-p4ww-qww8-jc5f</guid>
    </item>
    <item>
      <title>OESA-2024-2080 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2080</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
io_uring: fix memleak in io_init_wq_offload()&#13;
&#13;
I got memory leak report when doing fuzz test:&#13;
&#13;
BUG: memory leak
unreferenced object 0xffff888107310a80 (size 96):
comm &amp;amp;quot;syz-executor.6&amp;amp;quot;, pid 4610, jiffies 4295140240 (age 20.135s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
backtrace:
[&amp;amp;lt;000000001974933b&amp;amp;gt;] kmalloc include/linux/slab.h:591 [inline]
[&amp;amp;lt;000000001974933b&amp;amp;gt;] kzalloc include/linux/slab.h:721 [inline]
[&amp;amp;lt;000000001974933b&amp;amp;gt;] io_init_wq_offload fs/io_uring.c:7920 [inline]
[&amp;amp;lt;000000001974933b&amp;amp;gt;] io_uring_alloc_task_context+0x466/0x640 fs/io_uring.c:7955
[&amp;amp;lt;0000000039d0800d&amp;amp;gt;] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016
[&amp;amp;lt;000000008482e78c&amp;amp;gt;] io_uring_add_tctx_node fs/io_uring.c:9052 [inline]
[&amp;amp;lt;000000008482e78c&amp;amp;gt;] __do_sys_io_uring_enter fs/io_uring.c:9354 [inline]
[&amp;amp;lt;000000008482e78c&amp;amp;gt;] __se_sys_io_uring_enter fs/io_uring.c:9301 [inline]
[&amp;amp;lt;000000008482e78c&amp;amp;gt;] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301
[&amp;amp;lt;00000000b875f18f&amp;amp;gt;] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[&amp;amp;lt;00000000b875f18f&amp;amp;gt;] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
[&amp;amp;lt;000000006b0a8484&amp;amp;gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae&#13;
&#13;
CPU0…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
io_uring: fix memleak in io_init_wq_offload()&#13;
&#13;
I got memory leak report when doing fuzz test:&#13;
&#13;
BUG: memory leak
unreferenced object 0xffff888107310a80 (size 96):
comm &amp;amp;quot;syz-executor.6&amp;amp;quot;, pid 4610, jiffies 4295140240 (age 20.135s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
backtrace:
[&amp;amp;lt;000000001974933b&amp;amp;gt;] kmalloc include/linux/slab.h:591 [inline]
[&amp;amp;lt;000000001974933b&amp;amp;gt;] kzalloc include/linux/slab.h:721 [inline]
[&amp;amp;lt;000000001974933b&amp;amp;gt;] io_init_wq_offload fs/io_uring.c:7920 [inline]
[&amp;amp;lt;000000001974933b&amp;amp;gt;] io_uring_alloc_task_context+0x466/0x640 fs/io_uring.c:7955
[&amp;amp;lt;0000000039d0800d&amp;amp;gt;] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016
[&amp;amp;lt;000000008482e78c&amp;amp;gt;] io_uring_add_tctx_node fs/io_uring.c:9052 [inline]
[&amp;amp;lt;000000008482e78c&amp;amp;gt;] __do_sys_io_uring_enter fs/io_uring.c:9354 [inline]
[&amp;amp;lt;000000008482e78c&amp;amp;gt;] __se_sys_io_uring_enter fs/io_uring.c:9301 [inline]
[&amp;amp;lt;000000008482e78c&amp;amp;gt;] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301
[&amp;amp;lt;00000000b875f18f&amp;amp;gt;] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[&amp;amp;lt;00000000b875f18f&amp;amp;gt;] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
[&amp;amp;lt;000000006b0a8484&amp;amp;gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae&#13;
&#13;
CPU0…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2080</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:3190-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:3190-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2024:3190-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-48898</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-48898</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 91 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer There are 3 possible interrupt sources are handled by DP controller, HPDstatus, Controller state changes and Aux read/write transaction. At every irq, DP controller have to check isr status of every interrupt sources and service the interrupt if its isr status bits shows interrupts are pending. There is potential race condition may happen at current aux isr handler implementation since it is always complete dp_aux_cmd_fifo_tx() even irq is not for aux read or write transaction. This may cause aux read transaction return premature if host aux data read is in the middle of waiting for sink to complete transferring data to host while irq happen. This will cause host&amp;#39;s receiving buffer contains unexpected data. This patch fixes this problem by checking aux isr and return immediately at aux isr handler if there are no any isr status bits set. Current there is a bug report regrading eDP edid corruption happen during system booting up. After lengthy debugging to found that VIDEO_READY interrupt was continuously firing during system booting up which cause dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data from aux hardware buffer which is not yet contains complete data transfer from sink. This cause edid corruption. Follows are the signature at kernel logs when problem happen, EDID has corrupt header panel-simple-…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 91 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer There are 3 possible interrupt sources are handled by DP controller, HPDstatus, Controller state changes and Aux read/write transaction. At every irq, DP controller have to check isr status of every interrupt sources and service the interrupt if its isr status bits shows interrupts are pending. There is potential race condition may happen at current aux isr handler implementation since it is always complete dp_aux_cmd_fifo_tx() even irq is not for aux read or write transaction. This may cause aux read transaction return premature if host aux data read is in the middle of waiting for sink to complete transferring data to host while irq happen. This will cause host&amp;#39;s receiving buffer contains unexpected data. This patch fixes this problem by checking aux isr and return immediately at aux isr handler if there are no any isr status bits set. Current there is a bug report regrading eDP edid corruption happen during system booting up. After lengthy debugging to found that VIDEO_READY interrupt was continuously firing during system booting up which cause dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data from aux hardware buffer which is not yet contains complete data transfer from sink. This cause edid corruption. Follows are the signature at kernel logs when problem happen, EDID has corrupt header panel-simple-…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-48898</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1888 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1888</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1888</guid>
    </item>
  </channel>
</rss>
