<?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>Wed, 14 Oct 2026 17:33:32 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-21977 — fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-21977</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs&lt;/p&gt;
&lt;p&gt;Gen 2 Hyper-V VMs boot via EFI and have a standard EFI framebuffer
device. When the kdump kernel runs in such a VM, loading the efifb
driver may hang because of accessing the framebuffer at the wrong
memory address.&lt;/p&gt;
&lt;p&gt;The scenario occurs when the hyperv_fb driver in the original kernel
moves the framebuffer to a different MMIO address because of conflicts
with an already-running efifb or simplefb driver. The hyperv_fb driver
then informs Hyper-V of the change, which is allowed by the Hyper-V FB
VMBus device protocol. However, when the kexec command loads the kdump
kernel into crash memory via the kexec_file_load() system call, the
system call doesn&amp;#39;t know the framebuffer has moved, and it sets up the
kdump screen_info using the original framebuffer address. The transition
to the kdump kernel does not go through the Hyper-V host, so Hyper-V
does not reset the framebuffer address like it would do on a reboot.
When efifb tries to run, it accesses a non-existent framebuffer
address, which traps to the Hyper-V host. After many such accesses,
the Hyper-V host thinks the guest is being malicious, and throttles
the guest to the point that it runs very slowly or appears to have hung.&lt;/p&gt;
&lt;p&gt;When the kdump kernel is loaded into crash memory via the kexec_load()
system call, the problem does not occur. In this case, the kexec command
builds the screen_info…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs&lt;/p&gt;
&lt;p&gt;Gen 2 Hyper-V VMs boot via EFI and have a standard EFI framebuffer
device. When the kdump kernel runs in such a VM, loading the efifb
driver may hang because of accessing the framebuffer at the wrong
memory address.&lt;/p&gt;
&lt;p&gt;The scenario occurs when the hyperv_fb driver in the original kernel
moves the framebuffer to a different MMIO address because of conflicts
with an already-running efifb or simplefb driver. The hyperv_fb driver
then informs Hyper-V of the change, which is allowed by the Hyper-V FB
VMBus device protocol. However, when the kexec command loads the kdump
kernel into crash memory via the kexec_file_load() system call, the
system call doesn&amp;#39;t know the framebuffer has moved, and it sets up the
kdump screen_info using the original framebuffer address. The transition
to the kdump kernel does not go through the Hyper-V host, so Hyper-V
does not reset the framebuffer address like it would do on a reboot.
When efifb tries to run, it accesses a non-existent framebuffer
address, which traps to the Hyper-V host. After many such accesses,
the Hyper-V host thinks the guest is being malicious, and throttles
the guest to the point that it runs very slowly or appears to have hung.&lt;/p&gt;
&lt;p&gt;When the kdump kernel is loaded into crash memory via the kexec_load()
system call, the problem does not occur. In this case, the kexec command
builds the screen_info…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-21977</guid>
    </item>
    <item>
      <title>USN-7605-1 — linux, linux-aws, linux-gcp, linux-gcp-6.11, linux-hwe-6.11, linux-oracle, linux-raspi, linux-realtime vulnerabilities</title>
      <link>https://cve.radiocsirt.org/vuln/usn-7605-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux-gcp-6.11, Ubuntu:24.04:LTS: linux-hwe-6.11&lt;/p&gt;
&lt;p&gt;It was discovered that the CIFS network file system implementation in the
Linux kernel did not properly verify the target namespace when handling
upcalls. An attacker could use this to expose sensitive information.
(CVE-2025-2312)&lt;/p&gt;
&lt;p&gt;Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
  - ARM32 architecture;
  - ARM64 architecture;
  - PowerPC architecture;
  - x86 architecture;
  - Compute Acceleration Framework;
  - ACPI drivers;
  - Ublk userspace block driver;
  - Compressed RAM block device driver;
  - Bus devices;
  - AMD CDX bus driver;
  - Clock framework and drivers;
  - DMA engine subsystem;
  - DPLL subsystem;
  - Qualcomm firmware drivers;
  - GPIO subsystem;
  - GPU drivers;
  - HID subsystem;
  - IIO subsystem;
  - InfiniBand drivers;
  - Multiple devices driver;
  - Media drivers;
  - MemoryStick subsystem;
  - Network drivers;
  - Mellanox network drivers;
  - NTB driver;
  - NVME drivers;
  - PCI subsystem;
  - Pin controllers subsystem;
  - RapidIO drivers;
  - Voltage and Current Regulator drivers;
  - Remote Processor subsystem;
  - SCSI subsystem;
  - SLIMbus drivers;
  - QCOM SoC drivers;
  - VideoCore services drivers;
  - Thermal drivers;
  - USB DSL drivers;
  - USB Host Controller drivers;
  - Renesas USBHS Controller drivers;
  - USB Type-C Connector System Software Interface driver;
  - Virtio Host (VHOST) subsystem;
  - Fr…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux-gcp-6.11, Ubuntu:24.04:LTS: linux-hwe-6.11&lt;/p&gt;
&lt;p&gt;It was discovered that the CIFS network file system implementation in the
Linux kernel did not properly verify the target namespace when handling
upcalls. An attacker could use this to expose sensitive information.
(CVE-2025-2312)&lt;/p&gt;
&lt;p&gt;Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
  - ARM32 architecture;
  - ARM64 architecture;
  - PowerPC architecture;
  - x86 architecture;
  - Compute Acceleration Framework;
  - ACPI drivers;
  - Ublk userspace block driver;
  - Compressed RAM block device driver;
  - Bus devices;
  - AMD CDX bus driver;
  - Clock framework and drivers;
  - DMA engine subsystem;
  - DPLL subsystem;
  - Qualcomm firmware drivers;
  - GPIO subsystem;
  - GPU drivers;
  - HID subsystem;
  - IIO subsystem;
  - InfiniBand drivers;
  - Multiple devices driver;
  - Media drivers;
  - MemoryStick subsystem;
  - Network drivers;
  - Mellanox network drivers;
  - NTB driver;
  - NVME drivers;
  - PCI subsystem;
  - Pin controllers subsystem;
  - RapidIO drivers;
  - Voltage and Current Regulator drivers;
  - Remote Processor subsystem;
  - SCSI subsystem;
  - SLIMbus drivers;
  - QCOM SoC drivers;
  - VideoCore services drivers;
  - Thermal drivers;
  - USB DSL drivers;
  - USB Host Controller drivers;
  - Renesas USBHS Controller drivers;
  - USB Type-C Connector System Software Interface driver;
  - Virtio Host (VHOST) subsystem;
  - Fr…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/usn-7605-1</guid>
    </item>
  </channel>
</rss>
