<?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://vulnerability.circl.lu</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>Mon, 05 Oct 2026 23:36:36 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-39744 — rcu: Fix rcu_read_unlock() deadloop due to IRQ work</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-39744</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;rcu: Fix rcu_read_unlock() deadloop due to IRQ work&lt;/p&gt;
&lt;p&gt;During rcu_read_unlock_special(), if this happens during irq_exit(), we
can lockup if an IPI is issued. This is because the IPI itself triggers
the irq_exit() path causing a recursive lock up.&lt;/p&gt;
&lt;p&gt;This is precisely what Xiongfeng found when invoking a BPF program on
the trace_tick_stop() tracepoint As shown in the trace below. Fix by
managing the irq_work state correctly.&lt;/p&gt;
&lt;p&gt;irq_exit()
  __irq_exit_rcu()
    /* in_hardirq() returns false after this */
    preempt_count_sub(HARDIRQ_OFFSET)
    tick_irq_exit()
      tick_nohz_irq_exit()
	    tick_nohz_stop_sched_tick()
	      trace_tick_stop()  /* a bpf prog is hooked on this trace point */
		   __bpf_trace_tick_stop()
		      bpf_trace_run2()
			    rcu_read_unlock_special()
                              /* will send a IPI to itself */
			      irq_work_queue_on(&amp;amp;rdp-&amp;gt;defer_qs_iw, rdp-&amp;gt;cpu);&lt;/p&gt;
&lt;p&gt;A simple reproducer can also be obtained by doing the following in
tick_irq_exit(). It will hang on boot without the patch:&lt;/p&gt;
&lt;p&gt;static inline void tick_irq_exit(void)
  {
 +	rcu_read_lock();
 +	WRITE_ONCE(current-&amp;gt;rcu_read_unlock_special.b.need_qs, true);
 +	rcu_read_unlock();
 +&lt;/p&gt;
&lt;p&gt;[neeraj: Apply Frederic&amp;#39;s suggested fix for PREEMPT_RT]&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;rcu: Fix rcu_read_unlock() deadloop due to IRQ work&lt;/p&gt;
&lt;p&gt;During rcu_read_unlock_special(), if this happens during irq_exit(), we
can lockup if an IPI is issued. This is because the IPI itself triggers
the irq_exit() path causing a recursive lock up.&lt;/p&gt;
&lt;p&gt;This is precisely what Xiongfeng found when invoking a BPF program on
the trace_tick_stop() tracepoint As shown in the trace below. Fix by
managing the irq_work state correctly.&lt;/p&gt;
&lt;p&gt;irq_exit()
  __irq_exit_rcu()
    /* in_hardirq() returns false after this */
    preempt_count_sub(HARDIRQ_OFFSET)
    tick_irq_exit()
      tick_nohz_irq_exit()
	    tick_nohz_stop_sched_tick()
	      trace_tick_stop()  /* a bpf prog is hooked on this trace point */
		   __bpf_trace_tick_stop()
		      bpf_trace_run2()
			    rcu_read_unlock_special()
                              /* will send a IPI to itself */
			      irq_work_queue_on(&amp;amp;rdp-&amp;gt;defer_qs_iw, rdp-&amp;gt;cpu);&lt;/p&gt;
&lt;p&gt;A simple reproducer can also be obtained by doing the following in
tick_irq_exit(). It will hang on boot without the patch:&lt;/p&gt;
&lt;p&gt;static inline void tick_irq_exit(void)
  {
 +	rcu_read_lock();
 +	WRITE_ONCE(current-&amp;gt;rcu_read_unlock_special.b.need_qs, true);
 +	rcu_read_unlock();
 +&lt;/p&gt;
&lt;p&gt;[neeraj: Apply Frederic&amp;#39;s suggested fix for PREEMPT_RT]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-39744</guid>
    </item>
    <item>
      <title>USN-8028-1 — linux, linux-raspi vulnerabilities</title>
      <link>https://vulnerability.circl.lu/vuln/usn-8028-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux, Ubuntu:24.04:LTS: linux-raspi&lt;/p&gt;
&lt;p&gt;It was discovered that improper initialization of CPU cache memory could
allow a local attacker with hypervisor access to overwrite SEV-SNP guest
memory resulting in loss of data integrity. (CVE-2024-36331)&lt;/p&gt;
&lt;p&gt;Oleksii Oleksenko, Cedric Fournet, Jana Hofmann, Boris Köpf, Stavros Volos,
and Flavien Solt discovered that some AMD processors may allow an attacker
to infer data from previous stores, potentially resulting in the leakage of
privileged information. A local attacker could possibly use this to expose
sensitive information. (CVE-2024-36350, CVE-2024-36357)&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;
  - MIPS architecture;
  - PA-RISC architecture;
  - PowerPC architecture;
  - RISC-V architecture;
  - S390 architecture;
  - x86 architecture;
  - Block layer subsystem;
  - Cryptographic API;
  - Compute Acceleration Framework;
  - ACPI drivers;
  - Serial ATA and Parallel ATA drivers;
  - ATM drivers;
  - Drivers core;
  - ATA over ethernet (AOE) driver;
  - DRBD Distributed Replicated Block Device drivers;
  - Network block device driver;
  - Ublk userspace block driver;
  - Bluetooth drivers;
  - Bus devices;
  - Character device driver;
  - TPM device driver;
  - Clock framework and drivers;
  - Data acquisition framework and drivers;
  - CPU frequency scaling framework;
  - Hardware cryp…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux, Ubuntu:24.04:LTS: linux-raspi&lt;/p&gt;
&lt;p&gt;It was discovered that improper initialization of CPU cache memory could
allow a local attacker with hypervisor access to overwrite SEV-SNP guest
memory resulting in loss of data integrity. (CVE-2024-36331)&lt;/p&gt;
&lt;p&gt;Oleksii Oleksenko, Cedric Fournet, Jana Hofmann, Boris Köpf, Stavros Volos,
and Flavien Solt discovered that some AMD processors may allow an attacker
to infer data from previous stores, potentially resulting in the leakage of
privileged information. A local attacker could possibly use this to expose
sensitive information. (CVE-2024-36350, CVE-2024-36357)&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;
  - MIPS architecture;
  - PA-RISC architecture;
  - PowerPC architecture;
  - RISC-V architecture;
  - S390 architecture;
  - x86 architecture;
  - Block layer subsystem;
  - Cryptographic API;
  - Compute Acceleration Framework;
  - ACPI drivers;
  - Serial ATA and Parallel ATA drivers;
  - ATM drivers;
  - Drivers core;
  - ATA over ethernet (AOE) driver;
  - DRBD Distributed Replicated Block Device drivers;
  - Network block device driver;
  - Ublk userspace block driver;
  - Bluetooth drivers;
  - Bus devices;
  - Character device driver;
  - TPM device driver;
  - Clock framework and drivers;
  - Data acquisition framework and drivers;
  - CPU frequency scaling framework;
  - Hardware cryp…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/usn-8028-1</guid>
    </item>
  </channel>
</rss>
